* Adding condition compiler symbol to support .NET 3.5

This isn't useful to most users, but can be handy in advanced use cases,
as requested in #1465.

Also added a standalone formatter test, for confidence.
Have validated that undoing the change in 835fb947 breaks the tests
(i.e. we are still testing that the change is required).

(And likewise ignore the prefix in unpack.)

Fixes issue #1459.

JSON tests fail, as we're not using OriginalNameAttribute yet.

(NCrunch noticed these.)

Conflicts:
	csharp/src/Google.Protobuf/JsonFormatter.cs

This fixes issue #679 and issue #1282.
(The .gitignore change is just around ncrunch; I can put it in a separate PR if you really want.)

This was in an attempt to fix the wrapper handling corner case, but it's really fiddly.

This detects:
- An end-group tag with the wrong field number (doesn't match the start-group field)
- An end-group tag with no preceding start-group tag

Fixes issue #688.

The usage of ICustomDiagnosticMessage here is non-essential - ToDiagnosticString
doesn't actually get called by ToString() in this case, due to JsonFormatter code. It was
intended to make it clearer that it *did* have a custom format... but then arguably I should
do the same for Value, Struct, Any etc.

Moving some of the code out of JsonFormatter and into Duration/Timestamp/FieldMask likewise
feels somewhat nice, somewhat nasty... basically there are JSON-specific bits of formatting, but
also domain-specific bits of computation. <sigh>

Thoughts welcome.

"valueField": null

is parsed appropriately, i.e. that it remembers that the field is set.

Previously we were incorrectly packing wrapper types.
This also refactors FieldCodec a bit as well, using more C# 6-ness.

- Spot an Any without a type URL
- In the conformance test runner, catch exceptions due to generally-invalid JSON

This fixes issue #933, effectively.

On deserialization, missing values for message types
are replaced with a "default" message.

This involves quoting timestamp/duration/field-mask values, even when they're not in fields.
It's better for consistency.

Fixes issue #1097.

- Tighten up on Infinity/NaN handling in terms of whitespace handling (and test casing)
- Validate that values are genuinely integers when they've been parsed from a JSON number (ignoring the fact that 1.0000000000000000001 == 1 as a double...)
- Allow exponents and decimal points in string representations

This addresses issue #1008, by creating a JsonFormatter which is private and only different
to JsonFormatter.Default in terms of reference equality.

Other plausible designs:

- The same, but expose the diagnostic-only formatter
- Add something to settings to say "I don't have a type registry at all"
- Change the behaviour of JsonFormatter.Default (bad idea IMO, as we really *don't* want the result of this used as regular JSON to be parsed)

Note that just trying to find a separate fix to issue #933 and using that to override Any.ToString() differently wouldn't work for messages that *contain* an Any.

Generated code changes follow in the next commit.

This required a rework of the tokenizer to allow for a "replaying" tokenizer, basically in case the @type value comes after the data itself. This rework is nice in some ways (all the pushback and object depth logic in one place) but is a little fragile in terms of token push-back when using the replay tokenizer. It'll be fine for the scenario we need it for, but we should be careful...

Generated code changes for previous commit (basically InternalBuildGeneratedFileFrom => FromGeneratedCode)