USDZExporter: Anchoring support

[aleneum]

This is basically the same as #21997 by @ThorstenBux but with fixed white spaces. The problem wasn't too few tabs but too many in strings.

Original description:

Related issue: Fixed #21995

Description

Until these changes, it wasn't possible to tell AR Quicklook that a USDZ file should be attached to a wall target as opposed to a horizontal surface.

Reference: https://developer.apple.com/documentation/arkit/usdz_schemas_for_ar/preliminary_anchoringapi

This contribution is funded by Tripod Digital.

[aleneum]

I just realized that the added strings also contained tabs. I fixed that (I hope the indent is correct). I decided to squash this into one commit (and force push) to not inflate the commit history any further.

[donmccurdy]

@elalish curious on your thoughts here? If this anchoring data came with a glTF file via KHR_xmp_json_ld, would it be straightforward for model-viewer to adjust the generated USDZ to pass the anchoring data along?

[elalish]

@donmccurdy yes, I think so. We actually have our own API to specify wall-placement, so that will be our normal route. We would definitely use this feature in combination with our USDZ auto-generation.

[aleneum]

Hello again, since there hasn't been activity for 6 month and I am doing some 'repo cleaning' right now: Is this still a PR you are considering merging? Let me know if I could do something to make hitting that merge button easier for you. If this PR is not valid anymore I'd close this and delete my fork of three.js.

Cheers

[milesgreen]

+1 for this feature. Ability to specify floor or wall anchor when exporting USDZ would be great.

[elalish]

@mrdoob Any reason we can't merge this?

[Mugen87]

The API has slightly changed according to other exporters, see #24865. options is now a parameter of the parse() method.