Clean up Starlark options parser

[katre]

StarlarkOptionsParser is part of overall options parsing but still separate: it uses an entirely different API from OptionsParser and many code paths that handle options only handle native options as a result.

Ideally, native flags (based on OptionsBase and @Option) would use the same API as Starlark build settings.

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 type.

[katre]

This is motivated by code cleanups necessary for platform based flags.

[katre]

This probably also includes rationalizing and/or removing StarlarkBuildSettingsDetailsFunction