Move Standard Nodes specification to its own document (#2268)

In anticipation of imminent updates from the AOUSD group's work to create normative definitions of all MaterialX nodes, this PR moves the descriptions of the Standard Source Nodes and Standard Operator Nodes from the main Specification.md file into a new MaterialX.StandardNodes.md file.  This also updates hyperlinks throughout all .md files as needed to reflect the new organization, has a rewritten Compositing Nodes section to use the same "bullet-point" formatting as the other nodes, plus other minor typo and formatting fixes.

Author: dbsmythe

documents/Specification/MaterialX.GeomExts.md

@@ -51,6 +51,7 @@ There are many formats that can be used to describe the associations between sha
 
 **[References](#references)**
 
+<br>
 
 
 # Geometry Representation
@@ -142,6 +143,7 @@ So the following MTLX file snippets are equivalent:
   </materialx>
 ```
 
+<br>
 
 
 # Additional MaterialX Data Types
@@ -150,6 +152,8 @@ Systems supporting MaterialX Geometry Extensions support the following additiona
 
 **GeomName** and **GeomNameArray**: attributes of type "geomname" are just strings within quotes, but specifically mean the name of a single geometry using the conventions described in the [**Geometry Representation**](#geometry-representation) and [**Geometry Name Expressions**](#geometry-name-expressions) sections.  A geomname is allowed to use a geometry name expression as long as it resolves to a single geometry.  Attributes of type "geomnamearray" are strings within quotes containing a comma-separated list of one or more geomname values with or without expressions, and may resolve to any number of geometries.
 
+<br>
+
 
 # Additional Filename Substitutions
 
@@ -163,6 +167,7 @@ Filename input values for various nodes can include one or more special strings
 
 Only applications fully supporting Geometry Extensions may allow using a &lt;_geometry token_> as part of a larger filename string.  All applications should allow the use of "&lt;_geometry token_>" as the full filename string, in which case the string primvar value stored with the geometry is used as the filename unchanged; the string primvar value itself might be allowed to contain another token such as &lt;UDIM> which the renderer may be able to parse and replace itself.
 
+<br>
 
 
 # Geometry Info Elements
@@ -298,6 +303,7 @@ Workflows involving textures with implicitly-computed filenames based on u,v coo
   </geominfo>
 ```
 
+<br>
 
 
 # Look and Property Elements
@@ -510,6 +516,8 @@ This example defines four collections, a light shader and material, and a proper
 </materialx>
 ```
 
+<br>
+
 
 # References
 

documents/Specification/MaterialX.NPRSpec.md

@@ -12,7 +12,7 @@ July 1, 2024
 
 # Introduction
 
-The MaterialX Specification and MaterialX Physically Based Shading Nodes documents describe a number of standard pattern and shading nodes that may be used to construct nodegraph-based shaders for physically based rendering in a variety of applications.  However, there are certain operations that are desirable in non-photorealistic shading styles but which cannot be implemented within certain rendering constructs.  It is also helpful conceptually to separate nodes primarily useful for photorealistic and non-photorealistic shading styles into separate libraries.
+The [MaterialX Standard Nodes](./MaterialX.StandardNodes.md) and [MaterialX Physically Based Shading Nodes](./MaterialX.PBRSpec.md) documents describe a number of standard pattern and shading nodes that may be used to construct nodegraph-based shaders for physically based rendering in a variety of applications.  However, there are certain operations that are desirable in non-photorealistic shading styles but which cannot be implemented within certain rendering constructs.  It is also helpful conceptually to separate nodes primarily useful for photorealistic and non-photorealistic shading styles into separate libraries.
 
 This document describes a number of MaterialX nodes primarily applicable to non-photorealistic, or NPR, rendering.  Rendering applications whose architecture cannot support these operations are not required to support these nodes.
 
@@ -26,6 +26,8 @@ This document describes a number of MaterialX nodes primarily applicable to non-
 
 **[References](#references)**
 
+<br>
+
 
 # MaterialX NPR Library
 
@@ -64,6 +66,7 @@ This document describes a number of MaterialX nodes primarily applicable to non-
     * `shininess` (float): the specular power typically ranging from 1 to 256, defaults to 64.
     * `light_direction` (vector3): the incoming predominant lighting direction in world space, defaults to (1.0, -0.5, -0.5).
 
+<br>
 
 
 # References

documents/Specification/MaterialX.PBRSpec.md

@@ -48,6 +48,7 @@ This document describes a number of shader-semantic nodes implementing widely-us
 
 **[References](#references)**
 
+<br>
 
 
 # Physical Material Model
@@ -80,7 +81,7 @@ In general, a color given as input to the renderer is considered to represent a
 
 MaterialX supports the use of [color management systems](./MaterialX.Specification.md#color-spaces-and-color-management-systems) to associate colors with specific color spaces. A MaterialX document typically specifies the working color space that is to be used for the document as well as the color space in which input values and textures are given. If these color spaces are different from the working color space, it is the application's and shader generator's responsibility to transform them.
 
-The ShaderGen module has an interface that can be used to integrate support for different color management systems. A simplified implementation with some popular and commonly used color transformations is supplied and enabled by default. A full integration of OpenColorIO ([http://opencolorio.org](http://opencolorio.org)) is planned for the future.
+The ShaderGen module has an interface that can be used to integrate support for different color management systems. A simplified implementation with some popular and commonly used color transformations is supplied and enabled by default. An integration with the relevant portions of OpenColorIO ([http://opencolorio.org](http://opencolorio.org)) is planned for the future.
 
 
 ## Surfaces
@@ -135,6 +136,7 @@ Local lights are specified as light shaders assigned to a locator, modeling an e
 
 Light contributions coming from far away are handled by environment lights. These are typically photographically-captured or procedurally-generated images that surround the whole scene. This category of lights also includes sources like the sun, where the long distance traveled makes the light essentially directional and without falloff. For all shading points, an environment is seen as being infinitely far away.
 
+<br>
 
 
 # MaterialX PBS Library
@@ -411,6 +413,8 @@ Note that the standard library includes definitions for [**`displacement`**](./M
     * `color` (color3): Scattering color. Defaults to (1.0, 1.0, 1.0).
     * `azimuthal_roughness` (float): Azimuthal roughness, range [0.0, 1.0]. Defaults to 0.2.
 
+<br>
+
 
 # Shading Model Examples
 
@@ -456,6 +460,7 @@ This is an open surface shading model that was designed as a collaboration betwe
 A MaterialX definition and nodegraph implementation of OpenPBR Surface can be found here:  
 [https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/libraries/bxdf/open_pbr_surface.mtlx](https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/libraries/bxdf/open_pbr_surface.mtlx)
 
+<br>
 
 
 # Shading Translation Graphs
@@ -465,6 +470,8 @@ The MaterialX PBS Library includes a number of nodegraphs that can be used to ap
 * Autodesk Standard Surface to UsdPreviewSurface
 * Autodesk Standard Surface to glTF
 
+<br>
+
 
 # References
 

documents/Specification/MaterialX.Proposals.md

@@ -54,6 +54,11 @@ MaterialX should also support the following color spaces:
 
 ### AOV Output Elements
 
+(Summary for README.md: **New Support for Shader AOVs**
+
+Previously, MaterialX used custom types with a structure of output variables to define shader AOVs.  But this approach was not very flexible and in fact had not been implemented.  In v1.39, nodegraph-based shader implementations can include new [<aovoutput> elements](./MaterialX.Specification.md#aov-output-elements) to define AOVs which renderers can use to output additional channels of information in addition to the final shading result, while file-based <implementation>s can similarly define AOVs using [<aov> elements](./MaterialX.Specification.md#implementation-aov-elements).
+)
+
 A functional nodegraph with either a "shader" or "material"-semantic output type may contain a number of <aovoutput> elements to declare arbitrary output variables ("AOVs") which the renderer can see and output as additional streams of information.  AOVoutputs must be of type float, color3 or vector3 for pre-shading "pattern" values, or BSDF or EDF for shader-node output values; the renderer is expected to extract the appropriate color-like information from BSDF and EDF types.  AOVs defined within a shader-semantic node instantiated within this functional nodegraph may be "passed along" and potentially renamed (but may not be modified or operated on in any way) by providing a sourceaov attribute in the <aovoutput>.
 
 ```xml