[Feature] support third-party hosting integrations in aspire add/update via package metadata

## Is your feature request related to a problem? Please describe the problem.

I am trying to use `aspire add` and `aspire update` with third-party hosting integration packages, but the CLI currently has no explicit package-metadata-based way to discover or recognize them.

PR #16845 improved this area significantly by introducing `aspire integration list` and `aspire integration search` as the read-only discovery surface. However, discovery still appears to be limited by the current built-in integration matching rules, and there is still no clear package-level opt-in model for third-party hosting integrations.

In practice this means:
- third-party hosting integrations are harder to discover unless they happen to match the current naming assumptions
- `aspire add` cannot provide a consistent first-class workflow for those packages
- `aspire update` has no clear package-level signal for whether a third-party package should participate in Aspire integration update flows

This is especially relevant for polyglot app hosts, where CLI-specific bookkeeping should ideally not require changes to `apphost.ts` or other language-specific source files.

## Describe the solution you'd like

Introduce an explicit package-level opt-in for third-party hosting integrations via NuGet package metadata.

For example, define a well-known NuGet tag such as:

```xml
aspire-hosting
```

Packages that include this tag should be treated as Aspire hosting integrations by the CLI.

### Expected behavior

#### Discovery / `aspire add`

Packages tagged with `aspire-hosting` should be discoverable in:
- `aspire integration list`
- `aspire integration search`
- `aspire add`

This should be additive to the existing first-party and CommunityToolkit behavior, not a replacement for it.

#### `aspire update`

`aspire update` should also be able to account for these opted-in packages when determining which hosting integrations in the current project should be updated.

### Output / UX idea

It would also be helpful if the CLI output could distinguish between:
- Aspire-native integrations
- CommunityToolkit integrations
- third-party integrations

I do not have a strong opinion on the exact UX shape, but some kind of grouping or labeling in CLI output would make discovery much clearer.

For example, `aspire integration list` / `aspire integration search` could:
- group results by source, or
- display a label such as `Built-in`, `CommunityToolkit`, or `Third-party`

This would help users understand what is officially part of Aspire versus what comes from the wider ecosystem.

### Important constraints

The CLI should not require additional CLI-specific markers in source or project files solely for discovery/update support.

In particular, this should avoid requiring:
- extra markers in `apphost.ts`
- extra markers in `apphost.cs`
- extra `PackageReference` metadata written only for CLI bookkeeping

The package metadata should be the primary opt-in signal.

### `aspire.config.json` as project-local state

If project-local state is needed, especially for polyglot app hosts, `aspire.config.json` seems like a better place to store that than language-specific source or project files.

For example, the CLI could optionally persist which integrations are part of the current app in `aspire.config.json`, while still using package metadata as the source of truth for opt-in.

That would help keep polyglot scenarios clean while still giving `aspire update` enough project-local context.

### Prior art / related work

PR #16845 already established `aspire integration list` and `aspire integration search` as the non-interactive discovery surface. This proposal builds on top of that work by extending discovery and update behavior to support explicit third-party hosting integration opt-in via package metadata.

## Additional context

A concrete motivation is support for third-party packages such as:
- `Scalar.Aspire`
- `DevProxy.Hosting`

Those packages may represent valid hosting integrations, but they currently do not fit naturally into the existing CLI discovery/update flow.

It may also be worth documenting the recommended NuGet metadata convention for third-party hosting integrations if the team agrees on a canonical tag such as `aspire-hosting`.

Open design questions:
- Should `aspire.config.json` be the preferred project-local place to persist integration references for update scenarios, especially for polyglot app hosts?
- Should discovery output include explicit grouping or labels to distinguish built-in Aspire integrations from third-party ones?

Start by reading the discovery behavior introduced in PR #16845 and trace the `aspire add`, `aspire update`, `aspire integration list`, and `aspire integration search` entry points. Compare how package metadata and `aspire.config.json` could support third-party packages such as `Scalar.Aspire` and `DevProxy.Hosting`; done means tagged packages participate consistently without language-specific markers, with the intended output grouping or labeling defined.

Written by the indexing model from the issue text.