This enables the use of multiple --schema flags, and it also enables using both --reflect and --schema. By default, if a --schema flag is present, reflection is not used. But if one also explicitly specifies --reflect, then both will be used.

The value is that sometimes an RPC response may include extensions or messages inside google.protobuf.Any values that are not defined in the same schema that defines the RPC service. For reflection, this is usually less of an issue. But it can still be an issue if the RPC server also does not know about an extension or message inside an Any, which can happen when the data actually originates in some other server before being returned by the RPC handling server.

When not using reflection, the value is even greater, since it is quite common for extensions or error details to be defined in separate modules. Sometimes they are defined in dependencies of the RPC schema, but if the RPC schema doesn't directly import the files in question, they may be omitted (since downloading a module only includes the files in dependencies that are necessary to compile).

This addresses an issue raised in Slack:
https://bufbuild.slack.com/archives/CRZ680FUH/p1699560915612389
The user was using the reflection endpoint to download descriptors. However, the reflection endpoint schema does not know about any custom options that the user has defined. So the way for custom options to be "known" and included in the JSON representation of the response is to actually point buf curl at both schemas: the reflection module (which defines the RPC endpoint) and another (which defines the custom options).

So, without this change, we could only specify a single schema:

buf curl --netrc --schema buf.build/bufbuild/reflect \
    https://buf.build/buf.reflect.v1beta1.FileDescriptorSetService/GetFileDescriptorSet \
    --data @- <<EOM
{
  "module": "buf.build/bufbuild/knit-demo",
  "symbols":["buf.knit.demo.swapi.relations.v1.FilmResolverService"]
}
EOM

In the output of the above commands, all of the method options look like so:

    {
      "name": "GetStarshipFilms",
      "inputType": ".buf.knit.demo.swapi.relations.v1.GetStarshipRelationsRequest",
      "outputType": ".buf.knit.demo.swapi.relations.v1.GetFilmsResponse",
      "options": {
        "idempotencyLevel": "NO_SIDE_EFFECTS"
      }
    },

And if we use -v and also have #2586 applied, we see that it prints the following:

buf: Response message (buf.reflect.v1beta1.GetFileDescriptorSetResponse) contained 50 bytes of unrecognized fields.

So, with this branch, we can actually point buf at two schemas, including the one that defines the relevant custom options:

buf curl --netrc \
    --schema buf.build/bufbuild/reflect \
    --schema buf.build/bufbuild/knit \
    https://buf.build/buf.reflect.v1beta1.FileDescriptorSetService/GetFileDescriptorSet \
    --data @- <<EOM
{
  "module": "buf.build/bufbuild/knit-demo",
  "symbols":["buf.knit.demo.swapi.relations.v1.FilmResolverService"]
}
EOM

And now we see the output includes method options that look like so:

    {
      "name": "GetStarshipFilms",
      "inputType": ".buf.knit.demo.swapi.relations.v1.GetStarshipRelationsRequest",
      "outputType": ".buf.knit.demo.swapi.relations.v1.GetFilmsResponse",
      "options": {
        "idempotencyLevel": "NO_SIDE_EFFECTS",
        "[buf.knit.v1alpha1.relation]": {
          "name": "films"
        }
      }
    },