fix: schedule the #[Schedule] methods of the application's own classes

[ogorzalka]

A #[Schedule] method in the application's own classes (app/) was never scheduled. Its discovery is applied while Laravel boots, before WordPress has loaded cron.php: CronIndex::read() called the undefined _get_cron_array(), the Error was caught by apply(), and the logger of the service is null, so nothing was placed and nothing was said. Classes of a theme, a plugin or a module are applied later and were not affected.

Found on a throwaway project on the release head; the published framework v13.35.6 behaves the same (it called wp_next_scheduled(), defined in the same file), so this is not a regression.

When did_action('init') is 0 the placement now waits for init (priority 0, before any cron is spawned); later it is immediate, as before.

Checked live (framework dev-release/v13.36.0): the event of a class in app/ is placed on the first boot and not placed again, from the CLI and from a web request, on WP-Cron; on the laravel driver it runs and queues its next occurrence about an hour later (with Pollora/framework#477).

Test: applied before init, nothing is scheduled until the init callbacks run. 107 tests, PHPStan, Pint. No tag: for the v1.0.0.