[JIT] Remove BBF_NONE_QUIRK #95998

In the process of removing BBJ_NONE from the JIT's flowgraph code, #94239 introduced BBF_NONE_QUIRK to indicate a BBJ_ALWAYS block was previously a BBJ_NONE, and that if the block's jump target is the next block (thus mimicking fall-through behavior), the JIT should behave as if this block were still a BBJ_NONE. This decision was motivated by a desire to minimize diffs in the initial PR, and avoid tricky refactors in a few cases -- in particular, removing BBJ_NONE initially caused several small behavioral changes in Compiler::fgFindInsertPoint that cascaded into larger codegen diffs due to differences in block ordering. Introducing BBF_NONE_QUIRK somewhat alleviated these diffs.

As part of our broader effort of modernizing the JIT's flowgraph code (see #93020), we should prioritize removing BBF_NONE_QUIRK as we reduce our reliance on implicit fall-through behavior. As of writing, we set this flag in dozens of places, but we only check if it is set in four instances. I will outline these places below, in order of what I perceive to be increasing difficulty of removal:

• We assert BBF_NONE_QUIRK is set in importer.cpp. Removing this is trivial, and since this is during importation, I think asserting block->JumpsToNext() would be equivalent.
• In Compiler::placeLoopAlignInstructions, we check that the flag isn't present before considering placing align instructions after the block. Removing this check doesn't produce any diffs locally, so perhaps this is safe to remove? Perhaps it would make sense to not consider a BBJ_ALWAYS to the next block to better emulate the previous behavior with BBJ_NONE, but the jump target is subject to move, so maybe we don't need any additional check here. On the other hand, we currently don't try to remove jumps to the next block if the block with the jump has alignment padding at the end, so allowing more BBJ_ALWAYS blocks to have alignment might slightly reduce the possible applications of that optimization.
• In Compiler::fgUpdateFlowGraph, if a block's jump target is a BBJ_ALWAYS to the next block with BBF_NONE_QUIRK set, we don't attempt fgOptimizeBranchToEmptyUnconditional, as we might be able to compact the BBJ_ALWAYS later (which is what we initially did for BBJ_NONE blocks). Removing this restriction unlocks some dramatic code size improvements, though some of these improvements are due to the JIT deciding not to clone a loop. We will have to investigate why this affects decisions around loop cloning, and whether the reduced cloning is desirable or should be fixed.
• In Compiler::fgFindInsertPoint, we check BBF_NONE_QUIRK as a proxy for fall-through behavior when deciding whether to insert after a specific block. I think it makes sense to try to keep BBJ_ALWAYS blocks and their jump targets contiguous if they are already, though later decisions could move the two apart and render our initial decision here useless. Now that there are far fewer moving pieces to contend with than in JIT: Remove BBJ_NONE #94239, I'll try experimenting with this locally to see how sporadic the diffs are.

Thank you to everyone who's made an effort to remove BBF_NONE_QUIRK so far in otherwise unrelated changes (@jakobbotsch, I noticed you've removed a few instances in some of your recent work).