This addressbook.proto now belongs to its own bazel pacakge and can't be
accessed in bazel protobuf_test target.

Adds a proto_library rule for each well known type proto:

$ bazel query "filter(\".*_proto$\", \"...\")"
//:wrappers_proto
//:timestamp_proto
//:struct_proto
//:field_mask_proto
//:empty_proto
//:duration_proto
//:compiler_plugin_proto
//:descriptor_proto
//:api_proto
//:type_proto
//:source_context_proto
//:any_proto

Bazel users can reference these proto_library rules for their own
language specific rules i.e.

java_proto_library(
  name = "any_java_proto",
  deps = ["@com_google_protobuf//:any_proto"],
)

Also set the workspace name to "com_google_protobuf", as proto_library
rules reference protobuf that way.

Add implementations of open(2), mkdir(2), stat(2),
etc. that support long paths under Windows (paths
longer than MAX_PATH in <windows.h>, which is 260
characters).

The implementations are in a separate namespace
(google::protobuf::internal::win32), so they won't
collide with the standard implementations in
<io.h>, but after importing them with `using` they
can be drop-in replacements.

Fixes https://github.com/bazelbuild/bazel/issues/2634
Fixes https://github.com/google/protobuf/issues/2891

See: https://github.com/bazelbuild/bazel/issues/3198

Don't put gcc warnings options in copts, so that protobuf is able to
build by MSVC toolchain without python wrappers.

This target will be used by gRPC iOS bazel build system.

in order to avoid errors related to generics when 
building user code in newer versions of Java.

The first argument is currently implicitly a .bzl file.
Change this to be explicit.

This allows easy use of Bazel's java_proto_library native rule.

In pull request #2517 I made this change for the CMake and autotools
builds but forgot to do it for the Bazel build.

Bazel's built-in cc_proto_library rule uses a proto_lang_toolchain to learn how to invoke proto-compiler.
To use Bazel's cc_proto_library, add the following to your project's WORKSPACE file:

local_repository(
  name = "com_google_protobuf_cc",
  path = "/path/to/protobuf-distribution/"
)

Signed-off-by: Piotr Sikora <piotrsikora@google.com>

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`

proto3.

Added a couple unit test proto3 files, for arena_lite and lite. Cloned
the proto3_arena_unittest to test some of the basics of generated code
(and to ensure that the generated proto3 test files are used by some
test).

This is required to allow Tensorflow to build on Android without hacks. Currently we create a dummy pthread library just to satisfy this dependency for a library that does not exist on Android. See https://github.com/google/protobuf/issues/1373 for more context.