For Ed-Fi REST APIs, change how extensions are surfaced in order to resolve community confusion and collision issues

In the Ed-Fi REST APIs, extensions to existing API resources are currently co-mingled directly with existing resource properties. This creates substantial confusion as to which elements of the API resource (and Ed-Fi model) are core (i.e. common to all implementations) and which are non-standard (i.e. extensions that are not shared).

This confusion makes it very difficult for API client implementers to make efficient choices about development. A new client developer looking at an API resource will see no signals that an extension field is not a standard field.

This confusion is also a problem when an extension creates a whole new API resource.

A second smaller problem is that the current model allows no systematic way to share sets of extensions, due to the risk of naming collisions. Two extension sets could adopt the same field name yet with different definitions, making it impossible to run two sets of extensions. The hope is that extensions can be used by the community not as ways to act individually, but to act with others to explore new standardized models and vocabularies.

Looking at field evidence, you can see evidence that extensions to standards are typically segmented in some way (c.f. OneRoster)

This issue was extensively discussed with the community, including at the 2017 Technical Congress (see https://techdocs.ed-fi.org/display/EE/Agenda+-+2017+Technical+Congress?preview=/24151526/24152845/Ed-Fi_ODS_API_v3.0.pdf and also uploaded here) and via the Technical Advisory Group (see https://techdocs.ed-fi.org/display/EDFITAG/TAG+Meeting+2017-02-01 or https://techdocs.ed-fi.org/display/EDFITAG/TAG+Meeting+2016-11-03 among others) .