Auto merge of #160513 - Dnreikronos:assumptions_on_binders/enable_next_solver, r=lcnr,bit-aloo

session: Enable next-solver globally for assumptions-on-binders

Zulip: https://rust-lang.zulipchat.com/#narrow/channel/618216-t-types.2Fcall-for-participation/topic/assumptions.20on.20binders.3A.20enable.20next-solver.20automatically/with/614548133

`-Zassumptions-on-binders` already needs the next trait solver, but you still had to pass `-Znext-solver` by hand. Easy to forget, and some spots (feature gates) read `next_solver.globally` directly, so just special-casing `next_trait_solver_globally()` wouldn't cut it.

After `-Z` parsing, if assumptions-on-binders is on, force `NextSolverConfig { coherence: true, globally: true }`. Same pattern as `-Zretpoline-external-thunk`. Flag order doesn't matter. `-Znext-solver=no` gets overridden too; imo that's the right call since the assumptions code can't run on the old solver. A hard conflict error would also be fine, just more annoying for day-to-day hacking.

Covered the flag alone, both orderings, and `=no` in a unit test. Dropped the explicit `-Znext-solver` from one UI test under `assumptions_on_binders`.

btw idk if we should strip `-Znext-solver` from the rest of that folder asap or leave the redundancy. irl I'd leave it for now. fyi this also means anything checking `next_solver.globally` sees the effective config. ltm if you'd rather go the conflict-error route instead of overriding `=no`.