When Java raises a CharacterCodingException, the catch block rethrows this exception as a java.lang.Error.  Per the docs https://docs.oracle.com/javase/8/docs/api/java/lang/Error.html an Error is a serious problem that applications should not attempt to catch such as ThreadDeath.  In this case, it is reasonable for a consumer to try to catch this error as it likely indicates a problem with the underlying data. (#4630)

As Error does not inherit from Exception, a generic `catch(Exception ex)` will not catch this error.

A simple change from `Error` to `Exception` is not sufficient as an `Exception` is checked by the compiler, so in order to keep this issue unchecked, I am proposing raising a `RuntimeException` which is not checked, but is still a subclass of `Exception`.

The only possible breaking change would be if a consumer was explicitly catching `Error` already for this library.

https://github.com/google/flatbuffers/issues/4629

The ByteBufferFactory interface gives the user an option to specify
the method in which the internal ByteBuffer is allocated. This provides
flexibility in the type of ByteBuffer that can be used.
The sizedInputStream method is an alternative to sizedByteArray that
does not make a copy of the data in memory.

Tested: on Linux.

Change-Id: Iea336f75a3b6e722743563813c3c9ed9db4d02fe

Revert "Create a maven like project structure for java development. Make it OSGi compliant. Generate the flatbuffers code for testing (example)."

This reverts commit 9875b0e0.

Create a maven like project structure for java development. Make it OSGi compliant. Generate the flatbuffers code for testing (example).

Java developer are mostly comfortable with maven project structure. One one the main concept behind maven is convention. If you follow the maven project convention then your development team will get more effective as they now this project structure and can easily find the production code versus the test code.
 In this pull request I have structured the java project around 2 main parts:
  * the `flatbuffers` project. This project is the api / lib project and contains the test code structure + an example of code generation for testing. This avoid to commit generated code. Pre-configure JUnit for test driven development and make this project OSGi compliant.
  * the `jmh` project. This project aims to provide a placeholder for micro-benchmarking. JMH is a 'de facto' standard for micro benchmarking you can find more details here: http://openjdk.java.net/projects/code-tools/jmh/

For now I didn't move the JavaTest class but it could be a next step with a migration to the JUnit framework.
The only impacts are the move of the class and the project structure => no code change.

Removes the following allocations:
- ``CharsetDecoder`` is reused between calls
- ``CharBuffer#wrap`` removed in favor of heap
  based char buffer that is reused
- Temporary ``char[]``, an intermediate copy inside ``StringCoding``
- Another ``char[]``, this is needed because ``StringCoding`` uses
  a ``CharBuffer`` internally but returns a ``char[]``.  Extra
  characters need to be trimmed so this means yet another allocation
- Yet another ``char[]`` directly from ``__string`` for non-heap
  based buffers

Removes the following copies
- No copy is performed to trim the allocation since a ``CharBuffer``
  is used directly
- For non-heap based byte buffers, removes the copy that was
  previously done in the __string function

This does need to get the TLS entry which implies at least some
contention on the thread object table and a fence.

Adding an API reference for the supported languages.

General docs cleanup, including a new `tutorial` section that
supports all of the supported languages.

Added samples for each supported language to mirror the new
tutorial page.

Cleaned up all the links by making them `@ref` style links,
instead of referencing the names of the generated `.html` files.

Removed all generated files that were unnecessarily committed.

Also fixed the C# tests (two were failing due to a missing file).

Bug: b/25801305

Tested: Tested all samples on Ubuntu, Mac, and Android. Docs were
generated using doxygen and viewed on Chrome.

Change-Id: I2acaba6e332a15ae2deff5f26a4a25da7bd2c954

Change-Id: Id268e35de207c25c809a09071b81eea873c9123e
Tested: on Linux.

When accessing the array directly of a byte buffer, need to offset
by ``arrayOffset``

The satellite data of the ``ByteBuffer`` cannot be modified in
any way and stay thread safe in the presence of concurrent readers.

This implementation is simple and does introduce an allocation, however
without it multiple readers will quickly and continuously encounter
``IndexOutOfBoundsException`` exceptions.

An alternative, but possibly more controversial, implementation would
be to use ``Unsafe``.  Using ``Unsafe``, it's possible to do an
array copy with a provided buffer index.

Change-Id: I851d4034e753b3be2931ee2249ec2c82dde43135

Change-Id: I58b411a2c0f1ee6b856d5b1eaa42787036da1384

Bug: 16507831
Change-Id: I5beee18f63f174e425dc1ab395807b578d5f9477
Tested: on Linux.

Also cleaned up ByteBuffer usage in general: ByteBuffer.position
now universally indicates the start of a ByteBuffer.

Change-Id: Ic4bfb98f9df9501b8fc82de2c45db7d7311135ac
Tested: on Linux.

Also removed Table extend Constants.

Change-Id: I1770b613c58094fa572a3b26a31f01bd5fb8fdbf

Also fixed flatc not outputting these identifiers for files
compiled on the command-line.

Bug: 16983987
Change-Id: I8b714cfea3a8e144fa52133f62b2f7eda6eb044a
Tested: on Linux

Also added new constructor that allows ByteBuffer reuse.

Change-Id: I9c20ea96c67533066461f4e23b0d03b9b47cd068
Tested: on OS X.

Change-Id: If032b450230b15224b2661836c8a740398d207c5

Change-Id: I4c9f0f722490b374257adb3fec63e44ae93da920
Tested: using VS2010 / Xcode / gcc on Linux.