Support multiple values provided to options at the command line

The approved design (for now) is the following:

- The compiler will now support multiple values passed to an option at the command line using a comma-delimited string:

```
--option my-emitter.foo="three,four,five"
```
- Multiple specifications of the same option will not aggregate arrays of values across of them. The newest one always wins.
- Simple backslash-escaping of commas will be needed for strings that should not be treated as arrays

Other notes from the design meeting:

> Notes:
>
> * The future is using TypeSpec instead of JSON Schema, may be opportunities to drive better CLI parsing.
> * Can we perhaps just pass through string arguments to the emitter and let it handle it? It's possible, though maybe some downsides > (e.g. consistency of command line args, every emitter implementing splitter logic).
> * Type-directed arg parsing would allow us to use the option schema to interpret the CLI command more rigorously, passing emitters > scalars or arrays as necessary.
> * Possibly be consistent with yargs/azd? Spaces for separate args.
>
> Preferences:
>
> * Preference for handling this in the compiler as opposed to passing through to emitters and having them parse it.
> * Preference for string-with-commas: `--option my-emitter.foo="three,four,five"`.
> * Later, express options in TypeSpec, support aggregation, etc.

This is the implementation issue of #2092.