CMake prerelease versioning

Build examples in CMake

Make conformance tests more strict about the failure list.

OS X's version of Python has a slightly different error
message for this error case.

A series of improvements:

- Improved Protobuf module compatibility (disabled by default);
- Hide advanced settings;
- Added build tree configuration;
- Added build of examples.

Python 2.x doesn't detect unpaired surrogates so we have to
do that manually.

The failure lists were falling out of date because the
tests would pass even if people forgot to remove failures
from the list.

Add more context to GPBCodedInputStream failures.
Have GPBMessage parsing apis extract out the GPBCodedInputStream information and expose it.
Update HeaderDocs with pointers to all error domains/codes.
Expand the unittests to cover the full set of errors reported.

Fixes https://github.com/google/protobuf/issues/1618

Add https://github.com/os72/protobuf-dynamic

Add reference to Protocol Buffers Dynamic Schema (https://github.com/os72/protobuf-dynamic)

Update the list of places where the version is stored.

Bump cmake minimum required version to 2.8.12

add protobuf as3 lib and code generator for as3

Remove unused lines from CMake files.

Merge beta-3 release branch into master.

Removing unused GPBExceptionMessageKey

1.only support proto3
2.support oneof map
3.support nested message and enum for as3

https://github.com/google/protobuf/issues/1618

Add -Woverriding-method-mismatch.

fix expected class checking in GPBSetMessageRepeatedField

Fixes up the code to avoid some issues with isEqual: methods.

Opened https://github.com/google/protobuf/issues/1616 to track the KVC
collision.

This is currently checking for the wrong class for enums
and NSMutableArray fields.

Add more warnings to for the ObjC runtime build

Bazel build: Keep generated sources and Python runtime in the same directory

Users often encounter a Python import error when trying to build Python
protos if protobuf is installed locally on the machine. In this case,
Python ends up looking in the wrong directory when importing files (see
bazelbuild/bazel#1209 and tensorflow/tensorflow#2021). It seems that the
problem is caused by Python getting confused when there are Python
source files that are meant to be part of the same package but are
in separate directories.

Prior to #1233, the Bazel build setup would copy the Python
runtime sources and all generated sources for the builtin protos into
the root directory (assuming that the protobuf tree is vendored in a
google/protobuf directory).

With #1233, the two sets of sources are kept in their respective
directories but both `src/` and `python/` are added to the `PYTHONPATH`
using the new `imports` attribute of the Bazel Python rules. However,
both the runtime sources and the generated sources are under the same
package: `google.protobuf`, causing Python to become confused when
trying to import modules that are in the other directory.

This patch adds a workaround to the Bazel build to add a modified
version of the original `internal_copied_filegroup` macro to copy the
`.proto` files under `src/` to `python/` before building the
`py_proto_library` targets for the builtin protos. This ensures that the
generated sources for the builtin protos will be in the same directory
as the corresponding runtime sources.

This patch was tested with the following:
* All Python tests in protobuf
* All Python tests in tensorflow
* All tests in [Skydoc](https://github.com/bazelbuild/skydoc)
* Importing protobuf as `//google/protobuf`
* Importing and binding targets under `//external`
* Importing protobuf as `//third_party/protobuf`