Introduce rust_common struct

[hlopko]

This PR introduces a rust_common struct that will be used to access the Rust Sandwich API (the term first introduced in https://bazel.build/designs/2016/08/04/extensibility-for-native-rules.html and used ever since, for example https://blog.bazel.build/2017/03/07/java-sandwich.html :)

The motivation for this change:

• to provide a single place for other rule authors where they can see what APIs are available.
• to enable rule authors to make their custom rules interacting with Rust rules backwards and forwards compatible using the hasattr function. hassattr only works on struct fields, not on globals.

The plan is to eventually refactor uses of all private APIs to go trough rust_common.

Credit goes to brave owners of rules_swift who discovered how useful this approach is the hard way.

[UebelAndre]

Can you also add this to the docs in ./docs?

[illicitonion]

I find the naming a bit strange, as providers tend to take the form FooInfo (e.g. JavaInfo) - in the Java example, java_common.compile returns a JavaInfo and is typically referenced thus, rather than as java_common.compile...

I understand moving CrateInfo to a specific providers file, and making more clear what's public, but I'm not so clear on why rust_common is a useful wrapper layer?

[illicitonion]

I'm surprised this works, but I guess I can see how it would...!

[hlopko]

I understand moving CrateInfo to a specific providers file, and making more clear what's public, but I'm not so clear on why rust_common is a useful wrapper layer?

My thinking:

• having rust_common for functions is imho idiomatic way of structuring the sandwich in Bazel rules (C++, Java, proto, swift, objc all do the equivalent)
• the reason for above is also the hasattr (as noted in the PR description). hassattr only works on struct fields, not on globals.
• By hiding provider symbol behind it allows us to query the existence of provider in the far future when we decide to remove CrateInfo. This is mostly stockholm syndrome I have from updating Bazel rules :)

Am I making any sense?

[illicitonion]

• By hiding provider symbol behind it allows us to query the existence of provider in the far future when we decide to remove CrateInfo. This is mostly stockholm syndrome I have from updating Bazel rules :)

This is the only one I'm not super clear on, but I'll defer to your experience! :)

[UebelAndre]

Would still appreciate having docs updated 😅

[dfreese]

Would still appreciate having docs updated

I was looking for a way to handle that in an automated fashion on submit. There's probably a way to setup a github action to push to a "docs" branch and then serve the pages from there, but I need to look into it further.

[hlopko]

Discussed with Andre offline, right now the docs tooling doesn't support generating docs for structs, only rules and macros it seems.