Move responsibility for checking model requirements into `ModelRequirements` class

[felixarntz]

A small API enhancement:

• Currently, ModelConfig has a toRequiredOptions method, which is used as part of creating a ModelRequirements instance. This is not ideal, as it makes the ModelConfig class, a key component of both the implementer and extender APIs, dependent on the model discovery piece, which, while crucial, is of secondary nature when making LLM calls.
• Additionally, ModelMetadata has a meetsRequirements method, which similarly means it ties a key component to that model discovery piece.
• Both of these methods should be moved to another class.
• The original plan from ARCHITECTURE.md foresaw creating a RequirementsUtil class for this, but after discussion with @JasonTheAdams we don't think this is a solid solution either.

We think it would be best to put both of these functionalities into ModelRequirements.

For example as follows:

• public function areMetBy(ModelMetadata $metadata): bool
• public static function fromPromptData(CapabilityEnum $capability, list<Message> $messages, ModelConfig $modelConfig): self

This also means we should remove the private PromptBuilder::getModelRequirements method, as its logic will basically be moved to the second method above.

[felixarntz]

@Ref34t I realize you have started a PR #64 for RequirementsUtil, but per the above that may not be the cleanest solution.

Would you be interested in working on a PR for this issue instead?

[Ref34t]

@felixarntz Sure I'll give it my priority