Make plugin use betterproto generated classes internally

This means the betterproto plugin no longer needs to depend durectly on
protobuf.

This requires a small runtime hack to monkey patch some google types to
get around the fact that the compiler uses proto2, but betterproto
expects proto3.

Also:
- regenerate google.protobuf package
- fix a regex bug in the logic for determining whether to use a google
  wrapper type.
- fix a bug causing comments to get mixed up when multiple proto files
  generate code into a single python module

src/betterproto/lib/google/protobuf/compiler/__init__.py

@@ -0,0 +1,125 @@
+# Generated by the protocol buffer compiler.  DO NOT EDIT!
+# sources: google/protobuf/compiler/plugin.proto
+# plugin: python-betterproto
+from dataclasses import dataclass
+from typing import List
+
+import betterproto
+
+
+@dataclass(eq=False, repr=False)
+class Version(betterproto.Message):
+    """The version number of protocol compiler."""
+
+    major: int = betterproto.int32_field(1)
+    minor: int = betterproto.int32_field(2)
+    patch: int = betterproto.int32_field(3)
+    # A suffix for alpha, beta or rc release, e.g., "alpha-1", "rc2". It should
+    # be empty for mainline stable releases.
+    suffix: str = betterproto.string_field(4)
+
+    def __post_init__(self) -> None:
+        super().__post_init__()
+
+
+@dataclass(eq=False, repr=False)
+class CodeGeneratorRequest(betterproto.Message):
+    """An encoded CodeGeneratorRequest is written to the plugin's stdin."""
+
+    # The .proto files that were explicitly listed on the command-line.  The code
+    # generator should generate code only for these files.  Each file's
+    # descriptor will be included in proto_file, below.
+    file_to_generate: List[str] = betterproto.string_field(1)
+    # The generator parameter passed on the command-line.
+    parameter: str = betterproto.string_field(2)
+    # FileDescriptorProtos for all files in files_to_generate and everything they
+    # import.  The files will appear in topological order, so each file appears
+    # before any file that imports it. protoc guarantees that all proto_files
+    # will be written after the fields above, even though this is not technically
+    # guaranteed by the protobuf wire format.  This theoretically could allow a
+    # plugin to stream in the FileDescriptorProtos and handle them one by one
+    # rather than read the entire set into memory at once.  However, as of this
+    # writing, this is not similarly optimized on protoc's end -- it will store
+    # all fields in memory at once before sending them to the plugin. Type names
+    # of fields and extensions in the FileDescriptorProto are always fully
+    # qualified.
+    proto_file: List[
+        "betterproto_lib_google_protobuf.FileDescriptorProto"
+    ] = betterproto.message_field(15)
+    # The version number of protocol compiler.
+    compiler_version: "Version" = betterproto.message_field(3)
+
+    def __post_init__(self) -> None:
+        super().__post_init__()
+
+
+@dataclass(eq=False, repr=False)
+class CodeGeneratorResponse(betterproto.Message):
+    """The plugin writes an encoded CodeGeneratorResponse to stdout."""
+
+    # Error message.  If non-empty, code generation failed.  The plugin process
+    # should exit with status code zero even if it reports an error in this way.
+    # This should be used to indicate errors in .proto files which prevent the
+    # code generator from generating correct code.  Errors which indicate a
+    # problem in protoc itself -- such as the input CodeGeneratorRequest being
+    # unparseable -- should be reported by writing a message to stderr and
+    # exiting with a non-zero status code.
+    error: str = betterproto.string_field(1)
+    file: List["CodeGeneratorResponseFile"] = betterproto.message_field(15)
+
+    def __post_init__(self) -> None:
+        super().__post_init__()
+
+
+@dataclass(eq=False, repr=False)
+class CodeGeneratorResponseFile(betterproto.Message):
+    """Represents a single generated file."""
+
+    # The file name, relative to the output directory.  The name must not contain
+    # "." or ".." components and must be relative, not be absolute (so, the file
+    # cannot lie outside the output directory).  "/" must be used as the path
+    # separator, not "\". If the name is omitted, the content will be appended to
+    # the previous file.  This allows the generator to break large files into
+    # small chunks, and allows the generated text to be streamed back to protoc
+    # so that large files need not reside completely in memory at one time.  Note
+    # that as of this writing protoc does not optimize for this -- it will read
+    # the entire CodeGeneratorResponse before writing files to disk.
+    name: str = betterproto.string_field(1)
+    # If non-empty, indicates that the named file should already exist, and the
+    # content here is to be inserted into that file at a defined insertion point.
+    # This feature allows a code generator to extend the output produced by
+    # another code generator.  The original generator may provide insertion
+    # points by placing special annotations in the file that look like:
+    # @@protoc_insertion_point(NAME) The annotation can have arbitrary text
+    # before and after it on the line, which allows it to be placed in a comment.
+    # NAME should be replaced with an identifier naming the point -- this is what
+    # other generators will use as the insertion_point.  Code inserted at this
+    # point will be placed immediately above the line containing the insertion
+    # point (thus multiple insertions to the same point will come out in the
+    # order they were added). The double-@ is intended to make it unlikely that
+    # the generated code could contain things that look like insertion points by
+    # accident. For example, the C++ code generator places the following line in
+    # the .pb.h files that it generates:   //
+    # @@protoc_insertion_point(namespace_scope) This line appears within the
+    # scope of the file's package namespace, but outside of any particular class.
+    # Another plugin can then specify the insertion_point "namespace_scope" to
+    # generate additional classes or other declarations that should be placed in
+    # this scope. Note that if the line containing the insertion point begins
+    # with whitespace, the same whitespace will be added to every line of the
+    # inserted text.  This is useful for languages like Python, where indentation
+    # matters.  In these languages, the insertion point comment should be
+    # indented the same amount as any inserted code will need to be in order to
+    # work correctly in that context. The code generator that generates the
+    # initial file and the one which inserts into it must both run as part of a
+    # single invocation of protoc. Code generators are executed in the order in
+    # which they appear on the command line. If |insertion_point| is present,
+    # |name| must also be present.
+    insertion_point: str = betterproto.string_field(2)
+    # The file contents.
+    content: str = betterproto.string_field(15)
+
+    def __post_init__(self) -> None:
+        super().__post_init__()
+
+
+import betterproto.lib.google.protobuf as betterproto_lib_google_protobuf