* Give a unique category to each test.

This change introduce a TestCategory enum to ConformanceRequest. Existing tests
are divided into three categories: binary format test, json format test and json
format (ignore unknown when parsing) test. For the previous two categories, there
is no change to existing testee programs. For tests with the last category, testee programs
should either enable ignoring unknown field during json parsing or skip the test.

* Fix python test

* Fix java

* Fix csharp

* Update document

* Update csharp generated code

* Enable ignoring unknown in json parsing in php

* Update generated descriptor files

* Update failure list for other languages.

* Remove unnecessary php files

Add preserve UnknownFields
Compare floating point values bitwise
Add auto-generated header to C# generated files

 Add unknown field support for csharp

* Reserve unknown in ruby

* Revert ruby tests. Wait for cpp impl for conformance test

* Add conformance test for preserving unknown

* Add unknown field conformance test to csharp failure list.

* Fix comments

* Fix comment

* Fix comments

* Fix typo

* Use stringsink_string directly

* Mark hd unused

* Remove unused encodeunknown_handlerfunc

Previously we only rejected the tag if the tag itself was 0, i.e.
field=0, type=varint. The type doesn't matter: field 0 is always
invalid.

This removes the last of the C# conformance failures.

Add note about JSON tests maybe being wrong.

- Add note about the JSON test maybe not being correct yet.
- Add test to checks the generated names for double underscores to be sure they
  are what is expected.

This should fix the failures in the conformance tests - although
it highlights the problem that we need to do this when changing
the conformance.proto file...

Incase the different runtimes have different generation/implementations for
for the different primitive field types, cover a larger range of the proto
types in the oneof zero tests.

can reasonably be expected to be interoperable.

(The fact that not all Int64/Uint64 values *can* be exactly represented in
IEEE-754 and thus interoperably amongst JSON implementations is precisely the
reason for wrapping them when we serialize... it shouldn't be a surprise that
we can't round-trip in unwrapped form for all values.)

Python 2.x doesn't detect unpaired surrogates so we have to
do that manually.

We should now have no conformance failures.

The tests are run from Travis in the same way as on other
platforms. Currently some expected failures - but only expected
in that they're what we got to start with. Will try to fix them in
other pull requests.