Improve startViewTransition() data

[chrisdavidmills]

Summary

Chrome and Safari have both supported view transition types (see https://chromestatus.com/feature/5089552511533056) for a while, so it is high time I got them documented on MDN.

Having checked BCD, it seems that we have pretty much all of the data we need in place already, but I wanted to improve the Document.startViewTransition() data:

1. Originally, the method only took one parameter, a callback function.
2. It then got updated so that it can either take the callback function, or an options object containing the callback function as a property, plus a types array as a property.
3. The current data has two sub-data points:
   a. updateCallback makes sense — this is the callback parameter mentioned in 1.
   b. callbackOptions doesn't make sense. This refers to a mixin in the spec that represents the possible parameter values as one item. This is a spec construct and not a real value that developers can use. It would be better to have a sub-data point for the options object, with sub-sub-data points for the possible object properties. This last bit is maybe not totally necessary, but I thought it would be useful for developers who are specifically checking the compat table for types support.

This PR updates the data as described above, and also updates the spec URLs so they all point to the Level 2 of the spec

Test results and supporting details

Related issues

[github-actions]

Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

[caugner]

LGTM overall, but the nested parameters should not be nested according to BCD guidelines.

[caugner]

BCD guidelines suggest to not nest these:

Suggested change

	"types_property": {
	"__compat": {
	"description": "`types` property",
	"options_types_parameter": {
	"__compat": {
	"description": "`options.types` parameter",

[caugner]

/cc @ddbeck Is this a special case warranting an exception? (I don't remember understanding why we don't nest these.)

Edit: Nesting has the benefit of linting the child support data against the parent support data.

[chrisdavidmills]

Yeah, not nesting them seems a little odd to me.

[caugner]

Suggested change

	"update_property": {
	"__compat": {
	"description": "`update` property",
	"options_update_parameter": {
	"__compat": {
	"description": "`options.update` parameter",

[chrisdavidmills]

As an FYI, I've updated the Firefox support for these updates to "preview": see https://bugzilla.mozilla.org/show_bug.cgi?id=2001878.

Update: After more testing, I'm pretty sure it should just be "147", not "preview". There doesn't appear to be a pref to flip for this.