cargo_build_script: allow files for the fake tools defaults

[krasimirgg]

No functional changes intended.

These fallback tools were always built. Internally, we're running these in context where they will always be provided by the c++ toolchain and they end up being built in many different blaze configurations.

I've updated it so that the fallbacks attributes are allowed to be None with an extra check in the rule to ensure they are non-null if a cc toolchain is unavailable.

[dzbarsky]

Since this also hurts non-blaze users, a nicer solution would be to use function default for the attribute so the dependency can be removed if there is a cc toolchain present. Want to do that instead?

[krasimirgg]

Since this also hurts non-blaze users, a nicer solution would be to use function default for the attribute so the dependency can be removed if there is a cc toolchain present. Want to do that instead?

@dzbarsky: that sounds very interesting, could you give me a pointer to this function default pattern?

Another way to do this is: mark the attributes optional and fail() in code if there is no cc_toolchain... Updated this PR.

As a follow-up, @UebelAndre -- how important is that in no-cc_toolchain context these fallbacks defaults are real labels that point to real binaries? If not that important, I'm thinking we can clean up the label defaults so they are None by default and remove the currently-default targets such as //cargo/private:no_ar. What do you think?