Overhaul availability testing and add expected language options

* 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.

Author: domenic