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.

(NCrunch noticed these.)

Introduce a new nuget package, Google.Protobuf.Tools, basically to contain protoc on multiple platforms.

I've moved both protoc.exe and the proto files out of Google.Protobuf.
The .proto files aren't a slam-dunk, but it feels like they belong with protoc as you'd *use* them with protoc.
It's not clear to me whether we really need both an x86 and x64 version of protoc.exe, as x86 would work on 64-bit Windows anyway. Discuss :)

This makes no externally visible behavioral changes. Internally and non-behaviorally:

- We use a field (compiler-generated) to store the JsonName to avoid recomputing it repeatedly
- The documentation for JsonName is updated to reflect the meaning better
- Readonly autoprops and expression-bodied properties used where possible

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.

This is a start to fixing issue #1212. It won't help for test protos,
conformance etc, but it will definitely be better than nothing, and
would have highlighted a change in descriptor.proto which broken C#
earlier.