Improve support for Yarn dev dependency pruning via inline buildpack

For cases where the Node.js CNB is combined with another buildpack like the Ruby CNB which disables dev dependency pruning, it should be possible for a user to still handle dev dependency pruning for their application if they configure an [inline buildpack](https://buildpacks.io/docs/for-app-developers/how-to/build-inputs/use-inline-buildpacks/).

For Yarn, this pruning operation is unfortunately not as straightforward as it should be as there is a combination of built-in support and plugin-provided support:

| Version | Plugins Required | Command |
| --------|-----------------|-----------|
| Yarn v1 | | `yarn install --production` |
| Yarn v2 | [workspace-tools](https://github.com/yarnpkg/berry/blob/HEAD/packages/plugin-workspace-tools/README.md) | `yarn workspaces focus --production`|
| Yarn v3 | [workspace-tools](https://github.com/yarnpkg/berry/blob/HEAD/packages/plugin-workspace-tools/README.md) | `yarn workspaces focus --production`|
| Yarn v4 | | `yarn workspaces focus --production` |

This is why, for Yarn v2 and higher, the Node.js CNB provides a custom Yarn plugin to handle pruning operations as we can't guarantee that the user has configured the proper plugins. This custom plugin is currently invoked with `yarn heroku prune` where the environment variable `YARN_PLUGINS="/path/to/heroku-plugin"` is set to allow for the plugin to be dynamically loaded.

If a user wanted to use the `yarn heroku prune` command in an inline buildpack, they will not be able to do so because neither the path to the custom plugin nor the `YARN_PLUGINS` environment variable are exposed. This could be remedied by installing the custom plugin into a layer available at runtime and exporting the `YARN_PLUGINS` for subsequent buildpacks.