[clr-interp] Fix issue around compliance with the rules about lazy initialized basic block stack details

[davidwrighton]

• When we added support for basic blocks with undefined stacks to be initialized with a stack state via a backwards branch we missed the case of basic blocks which begin after a ret instruction

This fixes the jit\Methodical\tailcall\test_implicit tests.

[dotnet-policy-service]

Tagging subscribers to this area: @BrzVlad, @janvorli, @kg
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR fixes a bug in the CLR interpreter's basic block creation logic where basic blocks that begin after a ret instruction were not being properly created. This caused issues with lazy initialization of basic block stack details when such blocks were reached via backwards branches.

• Adds a call to GetBB to create a basic block entry for any instruction that follows a ret instruction
• Follows the same pattern already established for other control flow instructions (branches, throws, etc.)

[BrzVlad]

The fix is reasonable but if the code following the ret is the target of a branch, then it should already be created in CreateBasicBlocks. For CEE_RET instruction we set the linkBBlocks = false. I'm wondering if the issue is that the test in question has dead instructions following the ret opcode that should be ignored. I suspect an alternative fix could be done by bumping the IL pointer until we get to the start of a new bblock (if we reach the case at the start of instruction loop where pNewBB is NULL despite linkBBlocks being false).

[janvorli]

LGTM, thank you!

[davidwrighton]

@BrzVlad this is a case with dead il instructions not referenced by anything. As you say, we could bump the il pointer forward, but this should also work, and matches how all the other cases like this work.