refactor(vertexai): Split into separate libraries

[natebosch]

The current approach uses part files which cannot be imported
separately. One drawback of this approach is that any members which need
to be referenced by test code must be public to the library. Using
src/ libraries, as opposed to src/ part files, allows making APIs
that are "package private" by convention - they are public to the
library, but only exported through the src/ import.

One potential downside (alternatively seen as a benefit) of using
separate libraries is that private members are truly private to their
library, and we cannot make a member of a class private to the package.
The convention for package imports only allows top level declarations to
be considered non-public implementation details.

• Remove imports from the top level library. Replace part lines with
  export of the same files.
• Add explicit show clauses to the exports. This is what allows an API
  to be public when imported from the src/ library, but not exposed
  through the package public library.
• Change some private _toGoogleAI<TypeName> methods to extension
  methods. Use the name toGoogleAI since the specific type names are
  clear from context.
• Change some private _fromGoogleAI<TypeName> factory constructors to
  extension methods on the google AI SDk types. Name toVertex().
• Remove some unused private methods that were filled in for
  consistency. More extension members can be added as needed.
• Add an extension to expose the private field _googleAiModel from
  GenerativeModel.
• Add a top level method to forward to the private GenerativeModel
  constructor.
• Add TODO comments to stop exporting some methods that don't need to be
  public. These could have been private in the part pattern. For now
  they are exported for backwards compatibility, and we can remove them
  when we are ready for a major version bump.

[natebosch]

If you have any branches that don't merge cleanly with this I can hold off and land it whenever it's convenient.

This is a refactor I would recommend, but it's not urgent. Let me know if you have any questions about the reasoning or implications of this change.

If you want to go forward with this refactoring I can work on jumping through the CI hurdles.

[cynthiajoan]

If you have any branches that don't merge cleanly with this I can hold off and land it whenever it's convenient.

This is a refactor I would recommend, but it's not urgent. Let me know if you have any questions about the reasoning or implications of this change.

If you want to go forward with this refactoring I can work on jumping through the CI hurdles.

This is great, thanks for doing this! I'd prefer you to go ahead and get this in first. It's much cleaner.

[natebosch]

I've added some API docs to these members for now. I'd recommend dropping the lint which requires this - it currently doesn't understand "package private" APIs (which these all are), and we have found it to be the case that some APIs don't have any useful information to add - and in those cases we prefer omitting the docs to adding redundant docs.

[natebosch]

[cloud_firestore/permission-denied] The caller does not have permission to execute the specified
operation.

Are these flakes?
It looks like there might also be some failures on master branch - is it OK to merge on red CI in this repo?

[russellwheatley]

@natebosch - you can ignore the firestore e2e as they relate to using second database which doesn't have emulator support and thus uses a live firebase project, I have app check enforcement on the firestore API as I am testing something out. When this PR gets to review state, I'll remove enforcement 😄, just ping me here (I think enforcement will be removed sooner to be honest).

[natebosch]

OK. I think this should be good to go.

[russellwheatley]

Small nit for spelling, but LGTM