Add deprecations boot to capture load-time deprecations

[JuanVqz]

What

The DeprecationTracker only sees what a test actually exercises, and it only attaches once the suite is running. Deprecations that fire while the app itself loads (association, scope, and callback declarations evaluated as the class bodies load) either happen before the tracker exists or never get exercised at all, so they don't make it into a shitlist.

This adds a way to get those boot-time deprecations. deprecations boot keeps the app from eager-loading on its own, attaches the tracker first, and then eager-loads, so the declaration-time warnings get recorded.

deprecations boot          # current bundle
deprecations --next boot   # next bundle (sets BUNDLE_GEMFILE=Gemfile.next + BUNDLE_CACHE_PATH=vendor/cache.next)

It writes an ordinary shitlist to spec/support/deprecation_warning.boot.shitlist.json and summarizes it the same way info does.

These are deprecations, so they flag the APIs Rails is going to remove. Capturing them up front, even on an app with a thin suite, lets us clear them on our own schedule instead of scrambling during the bump.

Scope

This is eager-load deprecation capture, not boot smoke testing. It tells you which deprecated APIs the app's own code declares. It does not tell you whether the app boots or serves a request under the next bundle.

Notes

• It reuses DeprecationTracker rather than adding new capture logic (init_tracker, eager-load, after_run). That also means it talks to whichever deprecator the Rails version exposes: Rails.application.deprecators on 7.1+, and the ActiveSupport::Deprecation singleton before that. So it works from Rails 2 through 8.1.
• --next only gives you the full set once the next bundle already boots (dual boot is green). Before that, eager-load stops at the first breaking change, one at a time. When a boot fails or is refused, the command exits non-zero and says why, instead of pretending the app is clean.
• While adding the CLI smoke test, two pre-existing bugs turned up and are fixed here too: the executable required rainbow, which is no longer a dependency, so it wouldn't even load on a clean install; and deprecations run blew up with a NoMethodError before doing any work.

This is a starting point proposal, happy to hear other approaches.

[JuanVqz]

Closing in favor of #199, which solves the same problem from a better attach point.

This PR runs the capture inside rails runner, which hands the script an app that is already initialized. Anything the app warned about while its initializers ran is therefore gone before the tracker attaches, and models an initializer happens to reference are already loaded, so their class bodies never re-evaluate during eager_load! and never warn again.

Measured on freshly generated rails new --minimal apps with two deliberate probes, one warning from an initializer and one from a model class body: this approach captures 1 of 2 on both Rails 7.1.6 and 8.1.3, while #199 captures 2 of 2. On a real 3.2/4.0 dual-boot app, with both configured to succeed, this approach captured 167 unique warnings and #199 captured 189, a strict superset. Runtime is the same, both boot the app once.

Two smaller things #199 also resolves: the eager-load refusal path disappears, since attaching before initialize! means an environment that eager-loads during boot is captured rather than refused; and the config.eager_load guard here raises NoMethodError on Rails < 4.0, where that setting does not exist.

The two CLI bugfixes that were bundled into this branch shipped separately as #197 (undeclared rainbow require) and #198 (NoMethodError in deprecations run), so nothing from here is lost.