[glTF 2.1] Accessor Component Types

# Accessor Component Types

glTF 2.0 defines the following component types for accessors:

| `componentType` | glTF type | Simple name |
| --------------- | -------------------------------------------------- | ----------- |
| `5120` | _signed byte_ (and _signed byte_ normalized) | `int8` |
| `5121` | _unsigned byte_ (and _unsigned byte_ normalized) | `uint8` |
| `5122` | _signed short_ (and _signed short_ normalized) | `int16` |
| `5123` | _unsigned short_ (and _unsigned short_ normalized) | `uint16` |
| `5125` | _unsigned int_ | `uint32` |
| `5126` | _float_ | `float32` |

glTF 2.1 adds definitions for the following component types:

| `componentType` | glTF type | Simple name |
| --------------- | ---------------- | ----------- |
| `5124` | _signed int_ | `int32` |
| `5130` | _double_ | `float64` |
| `5131` | _half float_ | `float16` |
| `5134` | _signed int64_ | `int64` |
| `5135` | _unsigned int64_ | `uint64` |

glTF 2.1 does NOT require these new component types to be supported for all uses within glTF files, such as meshes. Individual properties in glTF still restrict the allowed component types for that property, and those restrictions are not changed by glTF 2.1. The addition to the glTF 2.1 specification is only about defining the existence of these new component types.

In order to use these new component types in existing glTF features, such as meshes, an extension would need to be created that allows this. For example, see [`KHR_accessor_float16` and `KHR_accessor_float64`](https://github.com/KhronosGroup/glTF/pull/2397).

## Use cases

Smaller component types (`float16`) can be useful for reducing file size for data with limited range or precision requirements.

Larger component types (`int32`, `float64`, `int64`, `uint64`) can be useful for data with large range or precision requirements, such as geospatial data, scientific data, and so on.

## Why this design

Having glTF 2.1 define the existence of these new component types allows for extensions to use them, without requiring each extension to define them.

No repository file, test, or entry point is named. Start by reviewing the accessor component-type tables in this issue and the referenced KHR_accessor_float16 and KHR_accessor_float64 extension work; done means the specification defines the new types without expanding existing property restrictions.

Written by the indexing model from the issue text.