Improvement idea: add `choice` prop to features giving a subclass

Just like the title says. There are feautres, where you choose something form an array of opitons, be it expertise, eldritch invocation or fighting style. Why not treat subclasses the same way?

Proposed structure:
```
{
"index": "otherworldly-patron",
"class": {
"index": "warlock",
"name": "Warlock",
"url": "/api/classes/warlock"
},
"name": "Otherworldly Patron",
"level": 1,
"desc": [
"At 1st level [yada yada]."
],
"choice: {
"choose": 1,
"type": subclass
from: "api/classes/warlock/subclasses"
}
"url": "/api/features/otherworldly-patron"
}
```

I know there is only one subclass in the SRD, but as y'all mentioned before, if something comes from a feature, you like to keep it within that feature, so why not add information about subclass choices to the feature giving you a subclass?

Examine the feature data structure in the repository, likely in a JSON file or TypeScript interface. Look for existing features with a 'choice' property to understand the pattern. The change involves adding a new 'choice' object with type 'subclass' and a 'from' URL. Check how subclasses are currently referenced and ensure the new structure aligns with the API design. Test by updating a sample feature and verifying the API response.

由索引模型根據 Issue 內容生成。