Pass ctx through C++ action construction

[dzbarsky]

Summary

Change the cc_common.compile, cc_common.link, cc_common.create_linking_context_from_compilation_outputs, and cc_common.register_linkstamp_compile_action boundaries to accept ctx. The boundaries convert an actions value supplied as ctx once for migration compatibility, while compile, link, LTO, and linkstamp implementations receive the rule context directly. Wrapped link_actions remain separate only where shareable or alternate-configuration link artifacts require them.

Rationale

The action-only parameters forced implementation code to recover the rule context repeatedly through actions2ctx_cheat. Passing ctx from rules_cc callers removes those downstream conversions and gives each implementation direct access to the exact rule context fields it uses.

[c-mita]

I believe the intent was to remove the usage of ctx, for functions receive the things that are actually required, and that this was simply incomplete.

Passing in ctx again would then be a step backwards on that particular road.

[dzbarsky]

I believe the intent was to remove the usage of ctx, for functions receive the things that are actually required, and that this was simply incomplete.

Passing in ctx again would then be a step backwards on that particular road.

That's fair, but is anyone actually working on that? OTOH landing this PR allows to remove this actions2ctx_cheat method from the Java host side, which gives a tanglible simplification/improvement to the system, and doesn't actually prevent anyone from doing this (very non-trivial) no-ctx cleanup in the future, if there is appetite.

(As an aside, I think it's fine to just wire ctx everywhere, rule_go tries to do a similar thing with wiring a go context everywhere instead of the real ctx, and it also has to resort to go._ctx cheat in some places...)

[lilygorsheneva]

I believe the intent was to remove the usage of ctx, for functions receive the things that are actually required, and that this was simply incomplete.

Passing in ctx again would then be a step backwards on that particular road.

@c-mita do you recall where or with whom this was discussed? Are there opinions on rules API design I should know about?

I generally like the idea of removing the low-complexity Java code but this would also require changing rules_swift's public API (its compile|link equivalents also don't take ctx; almost all other cc_common.compile|link call sites have ctx available) in addition to updating a lot of callers.

[trybka]

FWIW I asked on the original PR that added these,

why not actually allow these? (assuming the "cheat" here implies this is not a typically allowed thing)

and never received a response from the original author.

To my knowledge nobody is working on actually cleaning any of that up, but various folks are OOO for the week.
@lilygorsheneva and I will ask around and see if we can get a better picture, but my inclination is to just permit this.

I know other rulesets go to great lengths to avoid the passage of ctx objects, so I will see if I can glean a more satisfying positive reason to disallow this.