Resolve the actual browser for any "--browser" strings

Feature Request

Internally, there's lots of places where WXT makes assumptions about the strings people are using for the --browser flag. Common examples would be "chrome", "firefox", "safari", "opera", "brave", etc, but it can be anything.

The assumptions WXT makes are related to how it resolves specific things, like manifest options, that may only be supported by chrome or firefox or safari. But what if someone has both an "ios" target and a "safari" target? Any logic that checks wxt.config.browser === "safari" will miss ios, when ideally "ios" should result in the same manifest as "safari".

So WXT needs a way to resolve which browser to generate things for - but that is different from which label you're building under.

Proposing a few changes to the current ResolvedConfig and InlineConfig types:

1. Keep using InlineConfig#browser (--browser CLI flag) for the output directory, import.meta.env.BROWSER and related runtime constants
2. Introduce InlineConfig#targetBrowserMap: Record<TargetBrowser, " that has a good default, but that can be customized by projects to map different --browser strings to the actual browser the extension will run in
3. Introduce ResolvedConfig.actualBrowser: "chromium" | "firefox" | "safari" which is used when generating manifest or other browser-specific code. I'm not sure if opera (or future browsers/forks) but it could be added to the union in the future, and we'd have have to update the checks.

Is your feature request related to a bug?

I thought this was already implemented, but I must have done it somewhere else, never ported into WXT.

Discussion here: https://github.com/wxt-dev/wxt/pull/2581#discussion_r3727922886

What are the alternatives?

AFAIK there is no way to "know" if a --browser is chrome or not without a way to map custom values to their actual browser.

Additional context

Related to #2301

Start by reading the InlineConfig and ResolvedConfig type definitions and the discussion on PR #2581, then trace browser-specific manifest generation. Confirm how #2301 relates. Done means custom --browser labels can map to an actual browser while the original label remains available for output directories and runtime constants.