Add r-nmf recipe (0.28)

[tfenne]

NMF is stuck at 0.21.0 (2018) on both the r and conda-forge channels because it added an Imports dependency on Biobase, a Bioconductor package neither channel carries nor permits. bioconda already hosts bioconductor-biobase, so build against that instead.

Bot commands for PR management

Please use the following BiocondaBot commands:

Everyone has access to the following BiocondaBot commands, which can be given in a comment:

@BiocondaBot please add label	Add the please review & merge label.
@BiocondaBot please fetch artifacts	Post links to CI-built packages/containers. You can use this to test packages locally.

Note that the @BiocondaBot please merge command is now depreciated. Please just squash and merge instead.

Also, the bot watches for comments from non-members that include @bioconda/<team> and will automatically re-post them to notify the addressed <team>.

[tfenne]

The build and test (ARM) failure isn't a build/test problem with the recipe itself — r-nmf compiles fine and library('NMF') loads successfully. It fails in the separate mulled-build container test:

LibMambaUnsatisfiableError: Encountered problems while solving:
- package r-nmf-0.28-r45hdb9a6cf_0 is excluded by strict repo priority

That test always runs with --strict-channel-priority against conda-forge, local, bioconda (in that order). conda-forge currently publishes its own r-nmf for linux-64 and linux-aarch64 (stuck at 0.21.0, since current NMF added an Imports: Biobase dependency conda-forge can't satisfy) but not osx-arm64 — which is exactly why build_and_test-osx-arm64 passed and build_and_test-linux-aarch64 failed: strict channel priority excludes bioconda's package entirely on any platform where the name also exists upstream, regardless of version. I'd expect the same failure on the linux-64 GitHub Actions check once it runs.

I added skip-lints: in_other_channels following the pattern in r-alakazam/r-shazam (same situation: CRAN packages that gained a Bioconductor Imports dependency conda-forge can't carry), but that only silences the lint — it doesn't address the actual solver-level collision the mulled-build test hits on platforms where conda-forge still ships the name.

Before I pick a direction (drop linux-aarch64 from additional-platforms, rename the package, or something else), I'd appreciate guidance on how bioconda wants this handled — in particular whether r-alakazam/r-shazam are actually exempt from this collision somehow (conda-forge does still list them for linux-64) or whether their CI just hasn't hit a fresh, non-cached build/test recently. Happy to make whatever change is preferred.