ref(options): backport sentry OptionsResolver from 5.x

[Litarnus]

A while ago we introduced a custom OptionsResolver that works similar to the Symfony OptionsResolver but allows us to remove it as dependency and making the PHP SDK easier to install.

The new data collection configuration structure introduced nested configuration, which increased the necessity of the options resolver in the current major branch.

This PR replaces the symfony options resolver with the custom one but does not alter the required dependencies.

[sentry]

Bug: An invalid SENTRY_DSN environment variable causes a generic InvalidArgumentException during SDK initialization, without explaining why the DSN is invalid.
_{Severity: HIGH}

Suggested Fix

Modify the validation logic to catch the specific exception from Dsn::createFromString() and re-throw it or include its message in the InvalidArgumentException. This will provide developers with actionable information about why the DSN is considered invalid, restoring the helpfulness of the previous error reporting.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: src/OptionsResolver.php#L47-L59

Potential issue: The new `OptionsResolver` performs eager validation on default values
at construction time. If the `SENTRY_DSN` environment variable is set to an invalid
value, the `Options` constructor immediately throws a generic
`InvalidArgumentException('Invalid default for option "dsn"')`. This behavior is a
regression, as the previous implementation would fail later with a more descriptive
error. The current generic exception prevents developers from understanding what is
wrong with the DSN string, hindering debugging.

_{Did we get this right? 👍 / 👎 to inform future reviews.}