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

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.

(There are documentation changes and new fields in descriptor.proto that have resulted
in changes to the serialized descriptor, but no breaking changes for C#.)

(JSON parsing already does the right thing.)

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

Overview of changes:
- A new C#-specific command-line option, legacy_enum_values to revert to the old behavior
- When legacy_enum_values isn't specified, we strip the enum name as a prefix, and PascalCase the value name
- A new attribute within the C# code so that we can always tell the original in-proto name

Regenerating the C# code with legacy_enum_values leads to code which still compiles and works - but
there's more still to do.