Split this repo?

Our recent efforts to configure a multi-module repository [did not go well](https://github.com/google/gnostic/issues/283), but the motivating issue remains -- the growing applications in the `cmd` directory add dependencies that aren't needed by consumers of the generated code in the `openapiv2` and `openapiv3` packages.

Splitting the repo seems like a more conservative approach to this problem, at least in the sense that it's less reliant on a somewhat exotic and [less-understood](https://github.com/golang/go/issues/27056) Go feature that is at least lightly [discouraged](https://github.com/golang/go/wiki/Modules#should-i-have-multiple-modules-in-a-single-repository).

Possible reorganizations:
1. The first reorganization that I think of would be to move as much as possible to a new `gnostic-tools` repo, keeping the generated components in place. This avoids breaking users of these components, but would force users of the tools (like `protoc-gen-openapi` to look elsewhere).
2. Another would be to create new repos containing the generated artifacts (essentially, the contents of [openapiv2](https://github.com/google/gnostic/tree/master/openapiv2), [openapiv3](https://github.com/google/gnostic/tree/master/openapiv3), and possibly [discovery](https://github.com/google/gnostic/tree/master/discovery), either each in its own repo or all in one). These repos would be almost-entirely machine-generated from tools in the base `gnostic` repo, would have a very limited set of dependencies, and clients could switch to these at their convenience. These would be very similar to generated client libraries in the [googleapis](https://github.com/googleapis) org. This also preserves the issues and PR history of the main repo.

Of these, I prefer the second. Are there others that we should consider?

@Jefftree @morphar WDYT?