* Add Syntax enum and make file syntax checks check the enum
 * Made IsPacked a normal get method without ternary op
 * Moved IFieldAccessor.HasValue to IFieldPresenceAccessor
 * Change naming of GetIsExtensionsInitialized
 * Fixed stray text in summary text

* Add changelog for 3.9.x

* Revert "Make php message class final to avoid mocking (#6277)" (#6324)

This reverts commit 7f84a943.
This is just temporary. Eventually, we still want to roll forward this
change. Some users are complaining they need more time to clean up their
code.

* Update extract_includes.bat.in

File io_win32.h is not in directory google\protobuf\stubs under directory google\protobuf\io

* Set oneof case in array constructor (#6351)

Forgot to set it previously.

* Update protobuf version (#6366)

* Drop building wheel for python 3.4 (#6406)

https://github.com/matthew-brett/multibuild/pull/240

* Fix binary compatibility in FieldCodec factory methods (#6380) (#6424)

* Fix binary compatibility in FieldCodec factory messages

* Make default value parameter for current factories required

* Route old methods through default value overloads

* Remove ExtensionRegistry.Add(params) overload

* Rename ExtensionRegistry.Add(IEnumerable<Extension>) overload to AddRange

* Edit naming of parameters in Extension classes

* * Fix add API warnings to docs for extension APIs
* Rename internal ExtensionSet.GetValue to TryGetValue

* Disable javadoc error (#6371)

* Disable javadoc error

Actual fixes of the javadoc will be followed up

* Remove duplicated configuration

* Update javadoc plugin version

* Updated Bazel test script to use most recent Bazel version (#6413) (#6433)

I'm not exactly sure why, but this fixes the failing Bazel presubmit
test. Using the most recent version seems like a good idea anyway so
that we can make sure we're compatible with any new Bazel changes.

* [bazel] Add fixes for --incompatible_load_{cc,java,proto}_rules_from_bzl

* No need to update version in generated code (#6471)

generate_descriptor will handle that

* Update protobuf version (#6472)

* Compiler changes (extensions)

* Generated changes (extensions)

* Library changes (extensions)

* Adjusted a summary to indicate ContainingType can be null for extensions

* Compiler changes (custom option review + access level review)

* Generated code changes (custom options + access review)

* Library changes (custom options + access review)

* Support C# 6 with library changes

* Access HasValue by property

* Set access level of all extension classes to internal (revert in next PR)

* Added null checks to custom options

* Rebase on master and regenerate Conformance

* Removed second dictionary from ExtensionSet

* Rebased compiler changes

* Rebased generated code changes

* Rebased library changes + review changes

* Add more safety checks to extension accessors

* Remove instances where extension sets were unnecessarily allocated

* Remove cleared items from sets
Empty sets are now made null
IExtensionMessage -> IExtendableMessage

* Remove dead code from IExtensionValue impls

* Clean both repeated and single value extensions

* Add GetOrRegister method for repeated fields and allow clearing repeated extensions

* Add type safe ClearExtension methods, remove non-generic IExtendableMessage interface.

* Simplify ExtensionSet.TryMergeFieldFrom

* Rebase on master to resolve conflicts

* Fix Makefile.am

* Add ObjectIntPair to Makefile.am

This is primarily for access to comments, which would be expected to be available in a protoc plugin.

The implementation has two fiddly aspects:

- We use a Lazy<T> to avoid building the map before cross-linking. An alternative would be to crosslink at the end of the constructor, and remove the calls to CrossLink elsewhere. This would be generally better IMO, but deviate from the Java code.
- The casts to IReadOnlyList<DescriptorBase> are unfortunate. They'll always work, because these lists are always ReadOnlyCollection<T> for a descriptor type... but we can't use IList<DescriptorBase> as that's not covariant, and it's annoyingly fiddly to change the field to be of type ReadOnlyCollection<T>.

This performs more testing for field descriptors built from byte
strings too, but that's mostly incidental. The chief intent is to
check that cross-linking occurs.

Related to #658 and #5007.

With this fix, Unity using IL2CPP should work with one of two
approaches:

- Call `FileDescriptor.ForceReflectionInitialization<T>` for every
  enum present in generated code (including oneof case enums)
- Ensure that IL2CPP uses the same code for int and any int-based
  enums

The former approach is likely to be simpler, unless IL2CPP changes
its default behavior. We *could* potentially generate the code
automatically, but that makes me slightly uncomfortable in terms of
generating code that's only relevant in one specific scenario. It
would be reasonably easy to write a tool (separate from protoc) to
generate the code required for any specific set of assemblies, so
that Unity users can include it in their application. We can always
decide to change to generate it automatically later.

This consists of:
- Changing the codegen for the fixed set of options protos, to parse unknown fields instead of skipping them
- Add a new CustomOptions type in the C# support library
- Expose CustomOptions properties from the immutable proto wrappers in the support library

Only single-value options are currently supported, and fetching options values requires getting the type right
and knowing the field number. Both of these can be addressed at a later time.

Fixes #2143, at least as a first pass.

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

Recently, descriptor.proto gained a GeneratedCodeInfo message, which means the generated code conflicts with our type.
Unfortunately this affects codegen as well, although this is a part of the public API which is very unlikely to affect hand-written code.

Generated code changes in next commit.

There are corner cases where MessageDescriptor.{ClrType,Parser} will return null, and these are now documented. However, normally they *should* be implemented, even for descriptors of for dynamic messages. Ditto FieldDescriptor.Accessor.
We'll still need a fair amount of work to implement dynamic messages, but this change means that the public API will be remain intact.

Additionally, this change starts making use of C# 6 features in the files that it touches. This is far from exhaustive, and later PRs will have more.

Generated code changes coming in the next commit.

We now do this in protoc instead of the generation simpler.

Benefits:
- Generation script is simpler
- Detection is simpler as we now only need to care about one filename
- The embedded descriptor knows itself as "google/protobuf/descriptor.proto" avoiding dependency issues

This PR also makes the "invalid dependency" exception clearer in terms of expected and actual dependencies.

We now do this in protoc instead of the generation simpler.

Benefits:
- Generation script is simpler
- Detection is simpler as we now only need to care about one filename
- The embedded descriptor knows itself as "google/protobuf/descriptor.proto" avoiding dependency issues

This PR also makes the "invalid dependency" exception clearer in terms of expected and actual dependencies.

With this in place, generating APIs on github.com/google/googleapis works - previously annotations.proto failed.
Currently there's no access to the annotations (stored as extensions) but we could potentially expose those at a later date.

This is definitely not ready to ship - I'm "troubled" by the disconnect between a list of fields in declaration order, and a mapping of field accessors by field number/name. Discussion required, but I find that easier when we've got code to look at :)

Instead, introduce GeneratedCodeInfo which passes in what we need, and adjust the codegen to take account of this.

Changes in brief:
1. Descriptor is now the entry point for all reflection.
2. IReflectedMessage has gone; there's now a Descriptor property in IMessage, which is explicitly implemented (due to the static property).
3. FieldAccessorTable has gone away
4. IFieldAccessor and OneofFieldAccessor still exist; we *could* put the functionality straight into FieldDescriptor and OneofDescriptor... I'm unsure about that.
5. There's a temporary property MessageDescriptor.FieldAccessorsByFieldNumber to make the test changes small - we probably want this to go away
6. Discovery for delegates is now via attributes applied to properties and the Clear method of a oneof

I'm happy with 1-3.
4 I'm unsure about - feedback welcome.
5 will go away
6 I'm unsure about, both in design and implementation. Should we have a ProtobufMessageAttribute too? Should we find all the relevant attributes in MessageDescriptor and pass them down, to avoid an O(N^2) scenario?

Generated code changes coming in the next commit.

We'll see what I've missed when CI fails...

Update code already within Google.Protobuf.Reflection which was importing Google.Protobuf.DescriptorProtos

- Move types into Google.Protobuf.Reflection
- Change codegen to reflect that in generated types

Generated code changes coming in part 2

- The protos are no longer publicly exposed at all
- Oneof detection now works (as we default to -1, not 0)
- OneofDescriptor exposes the fields in the oneof
- Removed unnecessary code for replacing protos - remnant of extensions
- There's now just the non-generic form of IDescriptor

- FieldAccessorTable is now non-generic
- We don't have a static field per message type in the umbrella class. (Message descriptors are accessed via the file descriptor.)
- Removed the "descriptor assigner" complication from the descriptor fixup; without extensions, we don't need it
- MapField implements IDictionary (more tests would be good...)
- RepeatedField implements IList (more tests would be good)
- Use expression trees to build accessors. (Will need to test this on various platforms... probably need a fallback strategy just using reflection directly.)
- Added FieldDescriptor.IsMap
- Added tests for reflection with generated messages

Changes to generated code coming in next commit.

Everything should now be consistent - the only difference between files is the year (aside from generated files).

Fixes issue #531.

1) Remove CSharpOptions
2) A new version of DescriptorProtoFile (with manual changes from codegen - it would otherwise be Descriptor.cs)
3) Turn off CLS compliance (which we'll remove from the codebase entirely; I don't think it's actually relevant these days)
4) Add "public imports" to FileDescriptor, with code broadly copied from the Java codebase.
Lots more changes to commit before it will build and tests run, but one step at a time...