Support crate features

[davidzchen]

Cargo supports Features, which, according to the documentation is used for the following:

1. Specifying conditional compilation options
2. Specifying optional dependencies
3. Specifying clusters of optional dependencies, other features of the current crates, and/or enabling features in dependencies of this crate.

(1) is currently supported via the crate_features attribute, which sets flags to enable different conditional compilation features via cfg. More discussion and design work is needed in order to support (2) and (3).

[davidzchen]

+@dslomov @gregestren @laurentlb
+cc @acmcarther @mattmoor @damienmg

It is unclear to me which Bazel/Skylark abstractions this would map best to. The way features propagate across the dependency graph in Cargo makes it seem that aspects may be the way to go, but maybe some of Bazel's configuration features may help as well.

Thoughts?

[acmcarther]

I'm not sure we should support any special behavior for them at this time. For the purposes of a cargo integration, we can let cargo resolve them statically as part of a BUILD file generator.

It turns out that feature flags have a lot of nuance, not all of which is intentional or good. One part of that is how flags are additive globally within a cargo project-- something it seems not a lot of folks are even aware of.

One important caveat is dependencies based on the target itself. I'd suggest we make the target triple explicit as part of the BUILD file generation step (and default to whatever cargo infers), as it doesn't require any special support on our end at this time.

EDIT: clarified the last part.

[acmcarther]

I've been toying with this for a while, and I'm thinking the best immediate approach might be to have a series of "blessed configurations". We could then use the select and config features of Bazel to conditionally include dependencies.

To motivate this, Cargo's current feature/dependency enabling system allows you to combine an arbitrary combination of system properties to enable a feature or dependency. The system properties in play look like (from my platform):

x86_64-unknown-linux-gnu
+ [
    "debug_assertions",
    "target_arch: x86_64",
    "target_endian: little",
    "target_env: gnu",
    "target_family: unix",
    "target_feature: sse",
    "target_feature: sse2",
    "target_has_atomic: 16",
    "target_has_atomic: 32",
    "target_has_atomic: 64",
    "target_has_atomic: 8",
    "target_has_atomic: ptr",
    "target_os: linux",
    "target_pointer_width: 64",
    "target_thread_local",
    "target_vendor: unknown",
    "unix"
]

I'd suggest we map down to a series of "artificial configurations". One representative of "linux", one representative of "windows", and one representative of "darwin", and use those with cargo's feature resolution machinery to bucket up what's available to Cargo. We could add additional (or maybe facilitate user defined configurations) at some later point.

All of that said, this is heavily dependent on how we decide to integrate with cargo in #2