[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).