Add non-normative note about the current usage of mesh.extras.targetN…

…ames

Morph target names are not required to perform morphing. A real time application that consume glTF assets doesn't need morph target names in the general case. 

Rightly so, glTF doesn't impose assets to have target names, but it also doesn't provide a way to optionally add them.

It seems that, since the release of glTF 2.0 in mid-2017, a number of implementation (three.js, the official Blender exporter, UnityGLTF, a and at least one Maya exporter (and probably some others software, I haven't made a list, these are the few I'm aware of)).

This has been discussed in issue KhronosGroup#1036. 

The goal is to help implementations that wants to do so have a way to do so in an interoperably way. Currently this has been done by adding a `targetNames` extras properties to the object.

Maybe a more proper way would be to have an extension doing so, however, this practice is already quite widespread, so I would argue that at least documenting it here and integrate a better (and standardized) way of doing so in glTF 2.x/3.0 is the better thing to do.

I am not opposed to the idea of writing an extension to support morph target names, but that would add 2 *not really standard* way of doing it instead of the one already out in the wild.

specification/2.0/README.md

@@ -854,6 +854,46 @@ After applying morph targets to vertex positions and normals, tangent space may
 
 > **Implementation note:** The number of morph targets is not limited in glTF. A conformant client implementation must support at least eight morphed attributes. This means that it has to support at least eight morph targets that contain a `POSITION` attribute, or four morph targets that contain a `POSITION` and a `NORMAL` attribute, or two morph targets that contain `POSITION`, `NORMAL` and `TANGENT` attributes. For assets that contain a higher number of morphed attributes, renderers may choose to either fully support them (for example, by performing the morph computations in software), or to only use the eight attributes of the morph targets with the highest weights. 
 
+> **Implementation note:** *(the following note is non-normative)* Although morph target are referenced by their position in the `mesh.primitives[].targets` array, many tools and application can use and benefit for having an associated name to a morph target. This functionality is not currently  supported by the glTF 2.0 file format. 
+> In practice however, many current implementation will check for the presence of an array of strings in `mesh.extras.targetNames` of the same size as the morph target array. 
+> Each string of this array, if present, is a hint about the name of the morph target that can be presented in an user interface. See content of `extras` property in the example below :
+> This practice is not standard. A future version of the glTF file format may include a standard way to store morph target names.
+
+```json
+
+"meshes": [{
+	"extras": {
+		"targetNames": [
+			"ExpressionSmile",
+			"ExpressionCry"
+		]
+	},
+	"weights": [
+		0,
+		0
+	],
+	"primitives": [{
+		"attributes": {
+			"POSITION": 0,
+			"NORMAL": 1
+		},
+		"targets": [{
+				"POSITION": 2,
+				"NORMAL": 3
+			},
+			{
+				"POSITION": 4,
+				"NORMAL": 5
+			}
+		],
+		"indices": 6
+	}]
+}]
+
+```
+
+*(end of non-normative note about naming morph-targets)*
+
 
 ### Skins