Proposal : Named Values

(Related to [Generic Type System proposal](https://github.com/AcademySoftwareFoundation/MaterialX/issues/2148).)

# Problem

Current XML based system for describing node definitions and nodegraphs requires each specialization of the node to be spelled out explicitly (e.g. `ND_add_float`, `ND_add_color3`, `ND_add_vector2`, ...). This leads to a verbose data library, and encourages copy/paste authoring which can be prone to errors.

As well as the variation of types, each different type has different value strings that need to be authored.

## Solutions

The possible solutions suggested in the [Generic Type System proposal](https://github.com/AcademySoftwareFoundation/MaterialX/issues/2148) also needs a way to define values that correspond to the type. Most of the default values in the MaterialX Data Library are really just _zero_ or _one_. So in this proposal we suggest additional syntax to describe the concrete named values indirectly at their usage site.

The `` element should be extended with additional attributes to hold the concrete values for the named values.

The `value` attribute then uses a special token to identify the new named value syntax, including a label identifying which of the available named values to use.

The exact selection for these tokens and the list of provided named values is a subject for further debate, but for the sake of example, we're proposing the `value` attribute use the prefix `TypeValue:` to identify this new named value behavior. This proposal also recommends as a minimum `zero` and `one` always be provided as concrete named values.

## Example
Note here we intentionally don't take any opinion on any generic type mechanism, and instead make the named value proposal in isolation. This could be implemented even if none of the generic type suggestions above are actioned.

```xml

```

We use the prefix `TypeValue:` for a value to indicate that a named value is being used, the suffix (here `one` and `zero`) is then used along with the corresponding defined type for the value.

## Evaluation

As with the [Generic Type System proposal](https://github.com/AcademySoftwareFoundation/MaterialX/issues/2148), there are a number of different ways we could decide to evaluate this.

### Build time only

We could process the data library files at build time, and replace the `TypeValue:` tokens with the concrete values. This would have the advantage of not requiring any downstream integrations change their interactions with the data library files.

### Runtime evaluation only

We could install the files _as-is_ and extend methods like `ValueElement::getValueString()` to look up the concrete values at runtime. This has the advantage of potentially allowing for smaller MaterialX installations

### Build and/or runtime
Finally we could provide a build time configuration that would allow either build time or runtime evaluation of the named values.

No implementation file or test is named. Start by reviewing the data library files and the mentioned ValueElement::getValueString() entry point, then resolve whether named values should be handled at build time, runtime, or both; done requires an agreed syntax and evaluation approach.

Written by the indexing model from the issue text.