Add support for plugins to dynamically linked modules

[jeffcharles]

Description of the change

Changes from not supporting a plugin when creating dynamically linked modules to requiring a plugin when creating dynamically linked modules. This is a breaking change.

I've also updated the dynamic codegen to not emit calls to eval_bytecode for the default plugin.

Why am I making this change?

Part of #768. We want to support using plugins when building dynamically linked modules. And, as I mention in a comment, we never want to assume the import namespace in the Javy CLI, so we need a plugin to be specified so we can derive the import namespace to use from it.

For the change to stop emitting calls to eval_bytecode, we want to remove eval_bytecode from the default plugin and the first step to doing that is to stop emitting new calls to eval_bytecode. The requirement to specify a plugin when building new dynamically linked modules means we can be sure the plugin used in any execution environment also supports calling invoke with a null function assuming the same or a newer plugin is used in the execution environment as is used when invoking javy build -C dynamic -C plugin=....

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.

[saulecabrera]

Should this be emit-plugin?

[jeffcharles]

I haven't merged the PR where I rename the command yet. I assume this will register as a merge conflict if I merge that PR before this one or if I merge this PR and then try to merge that PR because PRs are changing the same line in different ways.

[jeffcharles]

And it looks like it did register as a merge conflict 🎉