-) using dupenv_s instead of getenv_s and calling strdup ourselves.
-) few impossible-to-obtain if checks.
-) various signed/unsigned casting.
-) using time_t instead of time32_t
-) checking output of FormatMessage for failures.
-) don't redefine _WIN32_WINNT without undefining it first.
-) fixed msvc's interlocked casting.
-) renamed AddPort to AddListeningPort.
-) added protobuf's third_party includes to search path.
-) added a missing definition for inet_ntop in mingw32.
-) removed useless declarations.

-) gpr_atm_no_barrier_load should actually return something.
-) If compiling under mingw32, your compiler is gcc and gcc atomics become available.

If for any reason, our definition of gpr_int64 is different from the definition of google::protobuf::int64, the virtual override would fail, as this needs to be of the precisely exactly the same type.
That change allows us to use protobuf's int64 definition.

So that cpu_posix.c can be left untouched for the other platforms.

tag. This can happen if the tag is actually an integer being
typecast to void*

To avoid breaking the API of existing Next calls, I've made
a new AsyncNext method with a tri-state return that indicates
whether there is a shutdown, an actual event, or a timeout.

Still needs proper testing for the AsyncNext method specifically.

If the deadline elapses, return true but have a null tag.

Use this to relax the acq_loads in some fd_posix assertions. The primary
goal here is to avoid masking potential iomgr races from tsan.

- The google default credentials now work with the cloud SDK.
- Verified end to end with print_default_credentials and fetch_oauth2
  tools.

Testing asan configuration with the latest clang compiler fails due to
the warning `-Winconsistent-missing-override`. This patch fixes it.

The mappings are a combination of useless, inaccurate, and harmful.
Leave them out until they are helpful and correct.

Fundamental issues:
 - If in need of mappings, a user would need HTTP -> gRPC code mappings.
   But the docs don't provide that since the mappings are not 1:1.
 - There _is no_ gRPC -> HTTP code mapping taking place in gRPC. This
   may change in the future, but until then the docs are misleading.

But even given those were resolved, there are additional issues. Two
obvious examples:
 - 501 Not Implemented is refering to HTTP methods such as GET and POST
   not being implement. That should not be used for gRPC methods not
   found (UNIMPLEMENTED).
 - 404 Not Found is for when the resource is not found. In gRPC, the
   resource is the gRPC method, not the parameters (NOT_FOUND). If there
   is a REST conversion layer on top of gRPC, then 404 would be
   appropriate, but that just shows that the mapping can not be
   canonical.