Let `Label#debugPrint` emit label strings in display form

[fmeum]

This is a reland of 30b95e337bdd871e9f9616f993b4670f5d827da6 with a different approach to emitting display form labels that avoids adding a new to_display_form() method to Label:

• In action command lines, which are the most frequent use of labels in rule implementation functions, labels are automatically emitted in display form since 9d3a8b02b95ed9b51e5d8902463df2b261cd8d15.
• In module extensions and repository rules, if labels can be turned into display form, the inverse of the repository mapping would need to be tracked in lockfiles and marker files for correct incrementality. Furthermore, allowing implementation functions to access apparent names would allow them to "discriminate" against them, thus possibly breaking the user's capability to map repos at will via use_repo and repo_name. Similar to how providers on a target can't be enumerated, it is thus safer to not provide this information to the implementation functions directly.

This change thus implements StarlarkValue#debugPrint for Label to allow ruleset authors to emit labels in display form in warnings and error messages while ensuring that Starlark logic doesn't have access to this information. print("My message", label) degrades gracefully with older Bazel versions (it just prints a canonical label literal) and can thus be adopted immediately without a need for feature detection.

This requires changing the signature of StarlarkValue#debugPrint to receive the StarlarkThread instead of just the StarlarkSemantics. Since debugPrint is meant for emitting potentially non-deterministic information, it is safe to give it access to StarlarkThread.

Also improves the Bzlmod cycle reporter so that it prints helpful information on a cycle encountered in a previous iteration of this PR.

Fixes #20486

RELNOTES: Label instances passed to print or fail as positional arguments are now formatted with apparent repository names (optimized for human readability).

[fmeum]

@tetromino I have one more, but it's purely mechanical. :-)

[fmeum]

@tetromino Could you take another look?

[fmeum]

@Wyverald @tetromino Friendly ping

[fmeum]

@bazel-io flag

[fmeum]

Fixed a build failure caused by concurrent changes.

[iancha1992]

@bazel-io fork 7.2.0

[fmeum]

@Wyverald Friendly ping

[iancha1992]

@tetromino friendly ping :) Also 7.2.0 RC1 is scheduled for next Monday, 5/13/2024 FYI