This started out as a minor code move of early-osr logic, but
became a more general refactor of the tiering decisions.

Early-OSR: the intent here is to trigger OSR as soon as possible
when matching OSR'd code is cached. Move this out of ShouldOptimize
(since it has side effects), and into a dedicated function that's
called early in the decision process.

Note that with this change, we no longer trigger normal TF optimization
along with the OSR request - TF tiering heuristics are already complex
enough, let's not add yet another special case right now.

Other refactors:

- Clarify terminology around OSR. None of the functions in TM actually
  perform OSR; instead, they only increase the OSR urgency, effectively
  increasing the set of loops that will trigger OSR compilation.
- Clarify the control flow through the tiering decisions. Notably,
  we only increment OSR urgency when normal tierup has previously been
  requested. Also, there is a bytecode size limit involved. These
  conditions were previously hidden inside other functions.

Bug: v8:12161
Change-Id: I8f58b4332bd9851c6b299655ce840555fb7efa92
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3529448Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79512}