Misc bugfixes

[dannymcgee]

Ignore Nx configuration's targets key

Nx targets are configured in a project's configuration file like this:

{
  ...
  "targets": {
    "<target-name>": {
      "executor": "<executor-name>",
      ...
    }
    ...
  }
}

Previously, this plugin had been using that <target-name> to determine which type of command to execute. However, users should be permitted to assign whatever string they'd like to those keys without affecting the behavior of the invoked executor. This PR reworks the parseArgs function to take a separate parameter for the cargo command to execute, which we determine solely by which of the plugin's executors was invoked.

Add a dedicated run executor

Inline with the above changes, a new @nxrs/cargo:run executor has been added to handle cargo run ... commands. This executor was actually the main motivator for the changes above — if the Nx config's target key is run, users can no longer use the shorthand form for invoking that target (i.e., nx <target> <project> instead of nx run <project>:<target>), because it collides with the built-in nx run command.

With these changes, the run executor can be configured like so:

{
  ...
  "targets": {
    "dev": {
      "executor": "@nxrs/cargo:run",
      ...
    }
    ...
  }
}

And users can invoke that target by running nx dev <project>.

The default output from this plugin's bin generator also now outputs the configuration above instead of using run as the target key, but users are welcome to change that key to whatever they'd like.

Additional changes to executor processing

• Support has been added for the bin argument, so you can specify a particular binary target when running build, run, etc. This fixes [bug] Cannot build when the crate and bin name differ #20.
• The parseArgs function will now pass any unknown options it receives directly through to cargo, after prefixing them with -- and converting them to kebab-case. This should help with future-proofing this plugin in the absence of specific updates to support additional arguments supported by cargo in the future.