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.

[jeffcharles]

Can we add a step to run tests for the codegen crate similar to the Test CLI step and a step to lint the codegen crate similar to the CLI crate?

[jeffcharles]

Can we add a target for testing the codegen crate and add it as a prerequisite for the tests target?

[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!