Schema description readers and writers should be more general

[corranrogue9]

We should update the reader and writer abstractions for schema descriptions (currently CSDL) to support other languages/formats. We should keep in mind that a customer might want to create their own implementations for some format the we don't know. We should use RSDL as a litmus test that our new abstractions. Also, add Xml somewhere in the name of the existing implementations.

[corranrogue9]

Possible duplicate of #2128

[corranrogue9]

XML, JSON, YAML, and RSDL should all be possible, and hopefully also implemented (at least XML and JSON should be implemented). Customers might also have their own formats.

At a high-level, we should follow a similar structure for reading and writing metadata as we currently have for how we read and write data.

[corranrogue9]

I am adding context from one of our investigations meetings to each of the EDM related work items. Please keep these scenarios in mind when investigating this work item:

It has been suggested (by myself) that removing the EDM interfaces and replacing them with concrete types where appropriate would be a good idea. 2 existing scenarios were enumerated for why the interfaces are necessary, 1 existing scenario was enumerated for why the interfaces are helpful (but not strictly necessary), 1 known future scenario was enumerated for why the interaces continue to be necessary, and 1 potential future scenario was enumerate for why the interfaces provide existensibility that wouldn't be available with concrete types.

Existing necessary scenarios

1. The interfaces are used today for mocking in unit tests
2. The interfaces could be used by customers to provide custom implementations for each type

Existing helpful scenarios

1. It is helpful to have a read-only view into the EDM models

Known future scenario

1. We want to allow customers to update their models after, for example, the model has been read from a CSDL file. The interfaces being a read-only view give the option for the concrete types to be used for post-read modifications, with the interfaces being used once those modifications are complete.

Potential future scenario

1. There is a potential scenario where the full model being loaded into memory is not necessary for a customer. With the current structure of the IEdmModel interface, this means that, if all other EDM types were concrete types, then any instance of IEdmModel would necessarily need to load portions of the model into memory even if those portions aren't used. A new implementation of non-model EDM interfaces would allow for this even though the concrete types would not.

[corranrogue9]

It came up recently that adding a derived type of EdmType that isn't explicitly part of the entity data model causes serialization and deserialization to no longer abide by the standard. This means that we want to limit the inheritance of EdmType, something that we can't do if we expose these types as interfaces.