Migrated code generation logic to it's own crate

[ianmarmour]

Description of the change

Splits Code Generation logic out into it's own crate (from CLI).

Things I attempted to do pro-actively here,

• Remove unnecessary dependencies from both the javy-codegen crate and the cli crate.
• Added documentation and ensured all public interfaces are documented in javy-codegen.
• Re-exported commonly used structs for ease of use.

Things we might want to change/add,

• Crate specific tests ? (Maybe)
• ???

Why am I making this change?

To enable runtime generation of WASM modules without shelling out to a CLI.

Checklist

• I've updated the relevant CHANGELOG files if necessary. Changes to javy-cli and javy-plugin do not require updating CHANGELOG files.
• I've updated the relevant crate versions if necessary. Versioning policy for library crates
• I've updated documentation including crate documentation if necessary.

Related PR's

877, 879

[jeffcharles]

Can we add the crate feature we talked about before so we can reduce visibility for the methods for working with the v2 and default plugins to the CLI crate?

Otherwise, I think it's a structurally sound change besides removing some methods from the public API.

[ianmarmour]

Can we add the crate feature we talked about before so we can reduce visibility for the methods for working with the v2 and default plugins to the CLI crate?

Otherwise, I think it's a structurally sound change besides removing some methods from the public API.

Totally forgot, of course!

[jeffcharles]

I noticed a few more things while looking at this today.

While the CLI integration tests provide some level of test coverage, I feel like those tests are not testing at least a couple default behaviours of the generator. So might be good to write some tests to ensure those behaviours are what we want and aren't changed unintentionally.

I imagine at some point in the future, it might make sense to migrate a bunch of the integration tests to use this crate instead of using the CLI which should help with more direct test coverage but it doesn't make sense to do that in this PR.

[jeffcharles]

Can we set this to "1.0.0-alpha.1" for now?

I want to version this crate independently of the CLI and javy library crate. The programmatic interface and default behaviour of the CLI can change independently of the API of this crate so I'd prefer not to couple the versions together.

[jeffcharles]

Can we put this in the module docs as well?

[jeffcharles]

I think we should add documentation for the Cargo features here just saying they're not for public use and the APIs are not stable. I was thinking similar to how things are documented in the javy library crate. It would also be good to add a core concepts section.

[jeffcharles]

Can we also add an automated integration test for this example code in this crate?

[jeffcharles]

What's the behaviour if the consumer does not set a plugin before calling generate? Also can we add a test for this case?

[jeffcharles]

What's the behaviour if the consumer does not set set_compression? On the CLI, we've generally compressed the source code by default.