OpenAPI file structure for Stoplight documentation

Is your feature request related to a problem? Please describe.

When we are building out the OpenAPI files within Stoplight, I believe we need to align on how we should structure the YAML files.

• Option A: 1 YAML file for all of the CDS APIs
• Option B: 1 YAML file for each of the CDS APIs

Describe the solution you'd like

I would like to pursue Option B which is the creation of a YAML file for each of the CDS APIs (Events, Curb, Metrics). This could make the documentation modular and easier to digest when being displayed through Stoplight.

Is this a breaking change

This isn't a breaking change since we have yet to finalize a full Open API version on our documentation

Impacted Spec

All APIs are impacted with this documentation standard.

Describe alternatives you've considered

We would want to use Stoplight to create shared models that can be referenced by multiple APIs if these are needed. This proposed structure does not conflict with previous decisions to maintain a single branch for each API version.

Additional context

Several members of the CDS WGSC collectively showed support for the option to move towards a model where 3 distinct files were used to document each API in the Oct 11th WGSC meeting.

The issue names no files or tests. Start by reviewing the current Stoplight/OpenAPI YAML layout and the CDS Events, Curb, and Metrics API definitions; done means each API has its own YAML file and any shared models are referenced consistently.