Split `:toolchain_type` to correctly cover all use cases

PR Checklist

Please check if your PR fulfills the following requirements:

What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature (please, look at the "Scope of the project" section in the README.md file)
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

Issue Number: #3795

See issue for details.

Split @rules_nodejs//nodejs:toolchain_type into @rules_nodejs//nodejs:runtime_toolchain_type and @rules_nodejs//nodejs:exec_runtime_toolchain_type.
@rules_nodejs//nodejs:runtime_toolchain_type is suited towards usage in the target environment (e.g. runtime for *_binary rule outputs).
@rules_nodejs//nodejs:exec_runtime_toolchain_type is suited towards usage within rule actions (e.g. running NodeJS directly).
Split behaviour is disabled by default, controlled by a new attribute incompatible_split_toolchains on;
- node.toolchain module extension tag.
- nodejs_register_toolchains macro.
- nodejs_toolchains_repo repository rule (private API).
:resolved_toolchain target moved into @rules_nodejs//nodejs. This makes it possible to access a NodeJS toolchain implementation without needing to know the name of a user controlled generated repository (e.g. for use inside a genrule defined in another ruleset).
Add new toolchain type @rules_nodejs//nodejs:compilation_toolchain_type suited to usage of NodeJS as a compiler (e.g. for snapshot generation) when the exec and target platforms need to be aligned. The exact platforms can still be different, but they should at least be compatible across OS and CPU.