Replace Mono jobs in unified-build pipeline with a standalone Mono pipeline

[mthalman]

Related:

• Unified-build official build is timing out a lot dotnet#2017
• .NET VMR official build process bar dotnet#2323

Goals:

• Prevent failing Mono builds from blocking the official VMR build
• Validate that Mono builds work across all feature bands (still an open question of whether it's needed for 2xx+)
• Keep it simple; we don't want an expensive infra cost to support this

This can be achieved by pulling out the Mono jobs from the unified-build pipeline into a separate, standalone Mono pipeline.

This pipeline can be triggered from all feature bands branches. In the case of 2xx+, it will build the 1xx branch as well in order to avoid any dependency on build IDs which would be used to pull down blob artifacts. Those 1xx artifacts can then be fed into the 2xx build easily because they exist within the same pipeline. Implementing this also resolves #5315.

For simplicity, we can run a subset of the scenario tests such that it's not required to pull down Microsoft artifacts that would otherwise be required. Pulling down Microsoft artifacts would require identifying the build ID that produced those artifacts.

[mthalman]

• Validate that Mono builds work across all feature bands (still an open question of whether it's needed for 2xx+)

@dotnet/distro-maintainers - For those of you planning to build 2xx or higher feature bands, are you planning to use Mono? Knowing this information impacts how much test validation we'll do for that configuration.

[mateusrodrigues]

Our immediate plans are to continue only shipping the 1xx feature band in the Ubuntu archive. We might look into providing higher feature bands through a separate PPA for developers that wish to use them, in which case we will need Mono for the s390x and ppc64le builds. We are adding this as a product backlog item and it will undergo a priority review for the next Ubuntu release (26.04).