Clean up Starlark options parser

[`StarlarkOptionsParser`](https://cs.opensource.google/bazel/bazel/+/master:src/main/java/com/google/devtools/build/lib/runtime/StarlarkOptionsParser.java) is part of overall options parsing but still separate: it uses an entirely different API from [`OptionsParser`](https://cs.opensource.google/bazel/bazel/+/master:src/main/java/com/google/devtools/common/options/OptionsParser.java) and many code paths that handle options only handle native options as a result.

Ideally, native flags (based on [`OptionsBase`](https://cs.opensource.google/bazel/bazel/+/master:src/main/java/com/google/devtools/common/options/OptionsBase.java) and [`@Option`](https://cs.opensource.google/bazel/bazel/+/master:src/main/java/com/google/devtools/common/options/Option.java)) would use the same API as [Starlark build settings](https://bazel.build/extending/config).

An ideal end state API might look something like this:

1. A top-level `OptionsParser` that is responsible for splitting flags into keys and values
1. Handling both `--flag value` and `--flag=value` syntax
2. Handling the `no` boolean-negation prefix
3. Possibly handling string->value object conversion
2. A number of plugins for the parser to actually identify specific options (and parse values?)
1. A FieldOptionPlugin that handles "native" flags on `OptionsBase` subclasses, annotated with `@Option`
2. A StarlarkOptionPlugin that handles Starlark flags (including loading the actual target and rule to determine options data).
3. A unified system for then reporting flags values, handling diffs and merges, etc.

All of this is ambitious and won't happen soon, but I do plan to start some degree of convergence in order to durably expose Starlark option metadata via the existing [`OptionDefinition`](https://cs.opensource.google/bazel/bazel/+/master:src/main/java/com/google/devtools/common/options/OptionDefinition.java) type.