Users will not be affected, as MSBuild is not case-sensitive.

The changes in C# code are also entirely for consistency; they
do not affect the tooling dll at runtime.

Closes #17884

protoc and gRPC codegens differently treat non-ASCII letter
characters and symbols other than underscores when constructing
their respective output filenames for generated .cs files.
This change reproduces their respective behaviors exactly.

Fixes #17661

- Design time build can be disable by setting DisasbleProtobufDesignTimeBuild to true

The Windows Nano Server Docker image does not support 32-bit executables.

See: https://docs.microsoft.com/windows-server/get-started/getting-started-with-nano-server#important-differences-in-nano-server
See: https://github.com/grpc/grpc/pull/13207#issuecomment-444846082
Close: #13098 (wontfix)

For files without known extension (e.g. Unix binaries) , NuGet can't tell files from directories,
so mention protoc and grpc_csharp_ext explicitly to avoid breaking nuget's directory layout.

Unfixes #13098, hopefully temporarily.

This is a complete set of tooling to build .proto files, with or without
gRPC services, in .csproj, both "classic" and SDK flavors, and a bare
minimum support for C++ projects.

Highlights and omissions:
 * By default, generated files are placed into project's intermediate
   directory under obj/, and treated as temporary generated sources.
 * The projects are highly customizabe thorugh item metadata on Protobuf
   items.
 * SDK projects only use Visual Studio new build system, and automatically
   import XAML property sheets that allow setting per-file properties,
   such as generated file access, and whether to expect gRPC outputs, from
   VS properties windows. This possibly requires VS restart after the
   package is added to solution. Classic projects cannot be extended this
   way, and only show Protobuf as the possible item; settings are modified
   by editing the project only.
 * For C++ projects, only the tool and standard proto import paths are
   provided, no custom targets yet. This is in the works.
 * gRPC and Protobuf scripts are separate, and everything is programmed to
   easily split the Tools package into one for Google.Protobuf and another
   for Grpc.Tools. This requires tighter coordination between the teams.
 * The tasks DLL knows about gRPC. I tried to use it to support gRPC in a
   script-only fashion, but using the tasks results in much cleaner
   scripts. This is probably how it should remain.
 * In multitarget projects (multiple frameworks) protoc files are compiled
   for each target, and also for Debug/Release configuration sepatately. A
   possible fix is in the works, but requries some MsBuild tooling fixes,
   so it will take a while.
 * There are 4 tasks. The "smart" task predicts protoc outputs, and knows
   things about protoc naming conventions. This supports only C# and C++.
   The "dumb" task simply invokes protoc in a language-independent way,
   and supports all languages known to protoc. In the (not very likely)
   case protoc is used with MsBuild for these languages, instructions for
   extending the build is provided in build script comments. The other 2
   tasks are one to detect current platform and therefore tools paths, and
   another to read protoc generated dependency file. We use it for C#, but
   custom project may opt not to use the dependecy files.
 * 64-bit tools for Windows (protoc and grpc plugin exe) have been removed
   from package, as Windows is alsways able to run 32-bit executable (and
   they are smaller and faster, and always preferred when 2G address space
   is enough).