This change fixes the following Chromium presubmit error:

  third_party/protobuf/csharp/src/Google.Protobuf.Test/project.json could
  not be parsed: Expecting property name: line 25 column 3 (char 482)

This affects cases with leading capital letters.

This breaks compatibility with previous C# releases, but
fixes compatibility with other implementations.

See #2278 for details.

[skip ci]

Change-Id: I1ba6f6372a08b5796570851336e1a548602f60da

[skip ci]

Change-Id: I1ba6f6372a08b5796570851336e1a548602f60da

This check adds a few constraints on the way to build a project when we have
a proto file which imports another one. In particular, on projects which
build both C# and Java, it's easy to end up with exceptions like

    Expected: included.proto but was src/main/protobuf/included.proto

A user may work around this issue, but it may add unnecessary constraints
on the layout of the project.

According to https://github.com/google/protobuf/commit/f3504cf3b1d456a843e8242fdee9ba0bf2991dc1#diff-ecb0b909ed572381a1c8d1994f09a948R309
it has already been considered to get rid of this check, for
similar considerations, and because it doesn't exist in the Java code

Add more JSON tests around underscores

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...

(This still doesn't fix the conformance tests, but at least
we're now consistent with the C++ code.)

(This still doesn't fix the conformance tests, but at least
we're now consistent with the C++ code.)

This also updates the version number to 3.0.0-beta4

We now just perform the optimization within AddRange itself.

This is a breaking change in terms of "drop in the DLL", but is
source compatible, which should be fine.

(Also fix a few more C# 6-isms.)

This fixes issue #1730.

Move to dotnet cli for building, and .NET Core (netstandard1.0) as target platform

This also updates the version number to 3.0.0-beta4

* Improve exception throwing implementation in collections

* Implement RepeatedField.AddRange.

This fixes issue #1730.

* Optimize AddRange for sequences implementing ICollection

(Also fix a few more C# 6-isms.)

* Remove the overload for Add(RepeatedField<T>)

We now just perform the optimization within AddRange itself.

This is a breaking change in terms of "drop in the DLL", but is
source compatible, which should be fine.

This is the only call to TypeExtensions.IsValueType, so we can remove
that method, making the whole type conditionally compiled out for .NET 3.5

* 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.

This doesn't currently change the ordering in the implementation, but allows us to do so in the future.
We also need to change
https://developers.google.com/protocol-buffers/docs/reference/csharp-generated#singular
which states "Finally, unlike Dictionary<TKey, TValue>, MapField<TKey, TValue> preserves insertion order of entries."
(We can just remove that sentence, I think.)