* chore(lint)

I accidentally let 2 pieces of lint in with my generated code.

* fix(generate-code): I did not generate all the required code for tests.

Change-Id: If927f3ea3fb3723088fa287f24bdd1ad43c8d1d1
Tested: on Linux.

This avoid to put the pom.xml file into the source directory. Normally the pom file is in a parent (/parent) folder and it is not mixed with the java source code.
An other thing is: this will make import of the project more easy from a IDE.

The side effect is that the target folder where maven build artifacts will move from the <flatbuffers>/java/target to <flatbuffers>/target therefore the gitignore file has been updated in consequences.

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.

JavaScript uses UTF-16 but FlatBuffers uses UTF-8. This commit tests the code
that does the conversion between the two encodings. The last entry in the array
is tricky because each code point actually requires two UTF-16 code units,
unlike the other examples. The current JSON output of flatc actually handles
this case incorrectly (it generates invalid JSON with UTF-8 code units). The
generated JavaScript code passes these tests fine, however.

This adds a JavaScript language target. The generated JavaScript uses Google
Closure Compiler type annotations and can be compiled using the advanced
compilation mode, which performs type checking and optimizations such as
inlining and dead code elimination. The generated JavaScript also exports all
generated symbols for use with Node.js and RequireJS. This export behavior
can be turned off with the --no-js-exports flag for use with Google Closure
Compiler.

Tested: on Linux.

Change-Id: I8f7bccf9b1ad87fea788f85e23fa69435758feca

Implement code generation and self-contained runtime library for Python.

The test suite verifies:
  - Correctness of generated Python code by comparing output to that of
    the other language ports.
  - The exact bytes in the Builder buffer during many scenarios.
  - Vtable deduplication correctness.
  - Edge cases for table construction, via a fuzzer derived from the Go
    implementation.
  - All code is simultaneously valid in Python 2.6, 2.7, and 3.4.

The test suite includes benchmarks for:
  - Building 'gold' data.
  - Parsing 'gold' data.
  - Deduplicating vtables.

All tests pass on this author's system for the following Python
implementations:
  - CPython 2.6.7
  - CPython 2.7.8
  - CPython 3.4.2
  - PyPy 2.5.0 (CPython 2.7.8 compatible)

Change-Id: Ifc10c54845ea7553586d1896d509314d68e9ab0f

We were looking for 'flatc' in motive/bin/Debug/flatc,
on Mac. It's actually built to flatbuffers/Debug/flatc.

Tested: OS X Yosemite, ndk-r10d. Also tested on Linux.
Change-Id: I9f1ecfe00c5f42fd9b6808b5a5da1c920487a4c2

Change-Id: Ifa6d9459c53ae60b9bf936d9468ec971ee282f14
Tested: on Linux and Windows.

FlatBuffer schema files can now optionally specify a hash attribute that
will allow someone writing json files to enter a string to be hashed
rather than a specific value. The hashing algorithm to use is specified
by the schema.

Currently the only algorithms are fnv1 and fnv1a. There are 32 bit and
64 variatns for each. Additionally, a hashing command line tool was
added so that you can see what a string will hash to without needing to
inspect the flatbuffer binary blob.

Change-Id: I0cb359d0e2dc7d2dc1874b446dc19a17cc77109d

Change-Id: I72e92183a7b5f4145ea51fcec29257dc9553a461

Change-Id: I34ea778fc791ecce3a8948de51dea6fe4389a3c6

Include C# codegen in flatc and .NET FlatBuffer access via the
FlatBufferBuilder class

Tested: on Windows.

Change-Id: If5228a8df60a10e0751b245c6c64530264ea2d8a

Bug: 16624362
Change-Id: Ia09ea404c0c11dd1dc6993a8cbd155bf8152b65f
Tested: on Windows & Linux.

Allows you to add, and test for the presence of a magic 4-char
string in a FlatBuffer.

Tested: on OS X.

Change-Id: I090692a9e4fb53bed3543279a28563e67132cba0

Implement code generation and runtime library for Go, derived from the
Java implementation. Additionally, the test suite verifies:

 - the exact bytes in the Builder buffer during object construction,
 - vtable deduplication, and
 - table construction, via a fuzzer derived from the C++ implementation.

Change-Id: Ib95a019c684891def2b50281e570b4843fea7baa

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