glTF 2.1 support in bevy_gltf

## What problem does this solve or what need does it fill?

Bevy's `bevy_gltf` support is currently centered on glTF 2.0, while Khronos has announced glTF 2.1 as a backward-compatible evolution focused on complex scenes, multi-file composition, improved packaging, and several quality-of-life improvements.

Supporting glTF 2.1 matters because it expands the kinds of runtime assets and scenes that Bevy can load interoperably, especially for workflows involving:

- composed multi-file scenes
- reusable referenced assets
- large packaged scene deliveries
- spatial metadata such as shapes and bounding volumes
- larger binary payloads
- stable object identifiers for tooling and runtime integration

This issue is intended to track the work needed to evaluate, design, and implement glTF 2.1 support in `bevy_gltf`.

## What solution would you like?

Add staged support for glTF 2.1 in `bevy_gltf`, while preserving compatibility with existing glTF 2.0 assets.

This should likely be tracked as a broader effort rather than a single PR.

At a high level, that support would likely need to cover:

- [ ] Accept and correctly version-check glTF 2.1 assets
- [ ] Evaluate support for GLB binary format v3 / 64-bit chunk lengths
- [ ] Support for complex-scene features such as `files`, `externalAssets`, and packaged external assets
- [ ] Support for new metadata and QoL features such as `uid` and thumbnails
- [ ] Evaluation of new geometry and scene-structure features such as shapes and bounding volumes
- [ ] Validation, test coverage, and documentation of supported versus unsupported glTF 2.1 features

Open design questions:

- How should `externalAssets` integrate with `AssetServer` and handle-based loading?
- What should the failure behavior be for unsupported but present glTF 2.1 features?
- Should shapes and bounding volumes be imported immediately as metadata/components even if Bevy does not yet consume them deeply?
- What is the minimum viable subset of glTF 2.1 that Bevy should support first?

## What alternative(s) have you considered?

- Continue supporting glTF 2.0 only for now and defer 2.1 until the specification is fully finalized
- Only support a minimal compatibility subset of glTF 2.1, without attempting complex scene composition initially
- Handle some 2.1 capabilities through Bevy-specific conventions instead of direct format support

The preferred direction is to track native glTF 2.1 support explicitly, even if the implementation lands in phases. That keeps discussion, design, and follow-up work visible in one place.

## Additional context

Relevant upstream references:

- [Khronos announcement](https://www.khronos.org/blog/introducing-gltf-2.1-with-complex-scenes)
- [glTF 2.1 tracking issue](https://github.com/KhronosGroup/glTF/issues/2585)
- [External Assets](https://github.com/KhronosGroup/glTF/issues/2586)
- [Bounding Volumes](https://github.com/KhronosGroup/glTF/issues/2587)
- [Packaging External Assets](https://github.com/KhronosGroup/glTF/issues/2589)
- [Unified File References](https://github.com/KhronosGroup/glTF/issues/2590)
- [Thumbnails](https://github.com/KhronosGroup/glTF/issues/2593)
- [64-bit binary format](https://github.com/KhronosGroup/glTF/issues/2594)
- [Non-sequential attributes](https://github.com/KhronosGroup/glTF/issues/2595)
- [Accessor component types](https://github.com/KhronosGroup/glTF/issues/2596)
- [Unique IDs](https://github.com/KhronosGroup/glTF/issues/2597)

Notes:

- glTF 2.1 is intended to be backward-compatible with glTF 2.0, but the specification work is still in progress.
- This issue should track Bevy support work, not assume every proposed upstream detail is final yet.
- It may make sense to split the implementation into separate follow-up issues once the design is clearer.