For each message, optionally generate a struct to provide the
forward-compatible builder API, with inherent methods
for field setters and the .build() method to produce the fully
initialized message struct.

If generation of builders is enabled with a name `Builder` for a message
named `Foo`, an impl block with the associated fn `Foo::builder()` is
appended to the top-level file scope, and the definition of the builder
struct `Builder` and its methods is appended to the module `foo`.

Reuse the helpers that generate field definitions for a message,
but use a mode to output code for the builder fields,
which must be private and devoid of docs and prost annotations.

The added Config::builder method populates a PathMap
with values given in the second argument to configure the builder name.

Adorn a struct with #[non_exhaustive] to showcase and test how
the builder API (and Default) can be used to forward-compatibly
construct values of generated message types,
while the struct initializer syntax is forbidden.

Some of the doc tests showcase working around name conflicts between
the associated function generated for the builder API and a getter
method generated by the Message derive for a field named `builder`.
Also verify the no-conflict case where the field does not have a getter
generated for it, so the `builder` associated fn is fine.

The test crates in tests-2015 and tests-no-std are uniformly named
"tests" to simplify boilerplate in the doc tests.

This allows plugging a message builder into other builders'
setters for fields of the message type without the need to
call .build().

The setter for field named `test` in proto must be named `r#test`.