Configuration doesn't block native -> Skylark rules migration

[gregestren]

Part of the Skylark build configuration project.

This is a tracking issue supporting the effort to re-implement all native Bazel rules (i.e. rules defined directly in the Bazel binary) in Skylark. This issue is considered closed when configuration no longer blocks that effort. That specifically means:

1. All --my_language_some_flag Bazel definition must be expressible in Skylark
2. All native configuration transitions must be expressible in Skylark

There's not much to do specifically for this issue. This is basically an aggregate of #5574, #5575, and #5577.

This complements the Bazel Configurability Roadmap. Write questions / comments / status updates here. See there for the bigger picture.

[gregestren]

April '19 update:

Ongoing challenges are the complicated types of some native flags. It remains a goal to be equally powerful with Starlark-defined flags without inheriting ugliness from, say, carbon copying exactly how native typing works today. Also current work on host / execution transitions requires some thought, since those make changes in native code that needs a corresponding Starlark API.

[gregestren]

Jan '20 update:

While ongoing work remains, the core APIs are implemented and solid. This no longer makes sense as a coherent wide-reaching bug. We should move these themes forward with specific feature requests for specific needs for specific rule classes.

Priorities are now determined by individual rule migration schedules vs. major blockers on any of this.