Merge Spellcasting, StartingEquipment, and Class Levels into Class objects.

Currently, the 1:1 relationships of Class->Spellcasting and Class->StartingEquipment exist in the schema as URL strings, rather than the data simply being embedded in the Class object. This only serves to reduce the size of the Class endpoint response, but complicates the digestion of the data rather a lot. Having separate endpoints for Spellcasting and StartingEquipment also creates difficulty maintaining consistency in the structure of internal references; where all other references are suited to using the APIResource structure, these are simply incompatible due to the shape of the referenced data.

As for Class Levels, the size cost of including *all* Level data in the class resource is much greater than for Spellcasting or StartingEquipment. It would perhaps be more suitable, however, to provide references to class levels as an array of APIResources, rather than the current method of supplying a URL that returns such a list. This would again simplify the digestion of the API data greatly, including by reducing the number of API calls that have to be made. Additionally, leaving the Levels endpoint intact allows levels to be queried separately from Classes, if desired.

**In summary:**
- Merge Spellcasting and StartingEquipment data directly into Class objects, get rid of corresponding API endpoints
- Provide Class Levels as an array of APIResources in the Class object, keeping Levels endpoint

All of this can be applied to Subclasses, also.

Another one to discuss is class Spell lists. Move them into Spellcasting, or directly onto the Class object, as an array of APIResources, like Levels?

Examine the Class, Spellcasting, and StartingEquipment objects in the schema to understand the current 1:1 relationships and URL references. Look at the Levels endpoint and how it's currently referenced. Determine how to embed Spellcasting and StartingEquipment data directly into Class objects and change Levels to an array of APIResources. Consider applying the same changes to Subclasses and decide on handling class Spell lists.

Escrito por el modelo de indexación a partir del texto del issue.