[FrameworkBundle][Messenger][Scheduler] Add framework.scheduler.use_messenger_routing

Wrapping every scheduled message in RedispatchMessage by default would
be a real behavior change (sync -> possibly async execution), so this
follows the same opt-in-then-flip pattern already used for
messenger.reset_on_message: a nullable boolean, deprecated while
unset, flipping default in 9.0.

- framework.scheduler.use_messenger_routing: bool|null, defaults to
  null. null keeps the current behavior and is deprecated, saying it
  will default to true in 9.0.
- SchedulerTransport (and its factory) take a $useMessengerRouting
  argument. When true, every scheduled message the message generator
  yields - attribute-declared tasks and #[AsSchedule] provider
  messages alike - is wrapped in a RedispatchMessage unless it already
  is one, so it goes through the senders configured for its class
  instead of running inline. An explicit "transports" option on a
  task still always wins. The deprecation itself is triggered lazily,
  from SchedulerTransport::get(), only when an actual unwrapped
  message is yielded, so an idle install (component present, nothing
  due) stays quiet instead of warning on every container build.
- PreRunEvent, PostRunEvent and FailureEvent carry the scheduled
  message instead of the RedispatchMessage wrapping it, so listeners
  keep matching on the task class once the option is on.
- ScheduledStamp serializes the trigger of its message context as a
  description, restored as a SerializedTrigger, so a task whose
  trigger holds a closure can cross a transport. The TriggerInterface
  normalizer, which already did this for the Symfony serializer, now
  returns that class. The payload keeps its shape and no __unserialize
  is added, so old payloads still decode and no string-typed property
  is ever assigned from one.
- RedispatchMessage::__toString() no longer renders a dangling "via"
  when no transport names are set, which is now the common case.
- symfony/scheduler requires symfony/messenger ^8.2 and conflicts with
  older versions: below 8.2, RedispatchMessageHandler still attaches
  an empty TransportNamesStamp, which makes the option a silent no-op.