* Add options for `expectedInputLanguages`, `expectedContextLanguages`, and `outputLanguage`. The former two are used for downloading additional material and early errors if the web developer's required input/context languages cannot be supported by the browser. The latter gives clarity about what to do given mixed-language inputs.

* Remove the `capabilities()` method and the accompanying `AI*Capabilities` classes. The reasoning is as follows:

  Those classes had three APIs: `available`, `createOptionsAvailable()`, and `languageAvailable()`. `languageAvailable()` wasn't clear if it was talking about input, context, or output languages. Now that we have explicit options for those three, we could fold language availability testing into `createOptionsAvailable()`. But then, we can note that the `available` property is kind of useless, as just knowing that some possible combination of options/languages is supported is not helpful for any known use case. So, the only real functionality we care about is testing whether a given set of options to `create()` is supported.
  
  This was previously done via `(await ai.apiName.capabilities()).createOptionsAvailable()`. We instead expose it via `await ai.apiName.availability()`. This name is a bit clearer, and this design also avoids the complexity where we have to retrieve all the availability information for every combination of options during the call to `capabilities()`, for later sync access. Now we can just retrieve the relevant information during the call to `availability()`.

This was previously discussed in webmachinelearning/prompt-api#29; see especially webmachinelearning/prompt-api#29 (comment). Closes #16.

See also webmachinelearning/prompt-api#69 and webmachinelearning/translation-api#31.

…tector

Add an `expectedInputLanguages` option to language detector creation API. This allows the browser to download relevant material if necessary, or fail-fast if a language the web developer needs to support is not available.

Then, remove the `capabilities()` methods and the accompanying `AI*Capabilities` classes.

* For translator, the only useful capabilities API was `(await ai.translator.capabilities()).languagePairAvailable()`. We simplify this to `await ai.translator.availability()`. This design also avoids the complexity where we have to retrieve all the availability information for every combination of options during the call to `capabilities()`, for later sync access. Now we can just retrieve the relevant information during the call to `availability()`.

  Also, by unifying on using the same options for `create()` and `availability()`, we fix #24.

* For language detector, the capabilities supplied both `(await ai.languageDetector.capabilities()).available` and `(await ai.languageDetector.capabilities()).languageAvailable()`. We simplify this into `await ai.languageDetector.availability()`, which can either take no arguments (emulating `available`) or take the same `{ expectedInputLanguages }` argument as `create()` (emulating `languageAvailable()`).

See also webmachinelearning/writing-assistance-apis#22 and webmachinelearning/prompt-api#69.

Implement the new APIs as described to
webmachinelearning/prompt-api#69, split the
existing `capabilities()` API to `availability()` and `params()`. The
old APIs are still kept on purpose and they will be removed soon. The
WPTs are updated accordingly.

Bug: 390459309
Change-Id: I70054f3debbef1a4f1be426d5a1caf4f1bc6354c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6181653
Reviewed-by: Fergal Daly <fergal@chromium.org>
Commit-Queue: Fergal Daly <fergal@chromium.org>
Commit-Queue: Mingyu Lei <leimy@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1416025}