or that interface with core and are only for internal use

- Use docblocks instead of single line comments
- Escape '*/'
- Indent 4 spaces to match protobuf
- Use single line namespace to match protobuf

For Flatbuffers compatibility.

From what I can tell, File::additional_headers is not used by gRPC
itself or its default protobuf implementation; it was added for
Flatbuffers support (it just returns "" for protobuf).

In the Flatbuffer case, the generated header contains references to
Flatbuffer gRPC glue code which is in a header in additional_headers.
Prior to this patch, this meant that the generated .h file could not
be included unless this glue file was included first.

Because the protobuf implementation of additional_headers returns
an empty string, I think this change should be safe to do and not
have unintentional consequences.

This file is shared with the Flatbuffers project as well, which does not
use "pb" file extensions.

This changes the import style for proto dependencies from a) to b).
a) "import a.b.c as x"
b) "from a.b import c as x"

Using statement a) causes problems when using __init__ files. If module
"a.b" has an __init__.py file which is importing the python generated
grpc code "a.b.d", then we cannot import a module named "a.b.c" because
the module "a.b" does not exist yet. In this case python will throw:
AttributeError: 'module' object has no attribute 'b'

This PR adapts the code to use the same logic as in:
/google/protobuf/compiler/python/python_generator.cc

This reverts commit 79759fea, reversing
changes made to dc36f4df.

Since

    #...
    class Service:

    class NextService:
    #...

without a body or `pass` under `Service` is invalid
Python, we ensure a `pass` statement is always
emitted to make the generated code valid.