feat(internal/librariangen): prototype of handling go-genproto

[jskeet]

@quartzmo This is a prototype, but I really want to refactor it if we want to go ahead.

My vision for this would be to have steps of:

1. main: parse the command line (as today)
2. build/release/etc packages:
3. parse and validate the request, load the repo config
4. map the repo type (from the repo config) for the function to operate on the request (or error if it's not supported)
5. execute the function

We'd then have a separate package for each "type" of repo (default (monorepo+gax+gapic generator), genproto - later the discovery libraries potentially) which would expose the appropriate functions.

I think that would disentangle things more clearly, but it's quite a bit of work, so I didn't want to start on it yet. It's easy to end up with circular dependencies between packages if we're not careful.

I do wonder whether we could put all of the initial parts (parsing the command line, parsing and validating the request, loading the repo config) into a single "main" package, to avoid having a lot of single-file packages. We could have packages of:

• main (can depend on everything...)
• config (the repo config, and probably move requests and responses here too): doesn't depend on anything else
• utility packages such as protoc, bazel, execv which can depend on config but only that
• package per repo type

Does that sound plausible? (I suspect we'll want an actual design doc for this before going further, and potentially think about how this might work with moving the code into the librarian repo - what parts of it would be cross-language.)