Add a .implicit name specification, for @Option initializers

Properties wrapped by ``@Option`` with a ``.implicit`` name specification would be handled like those with ``@Argument`` and would allow command line tools like this one (inspired from sed).

```swift
import ArgumentParser

struct MySed: ParsableCommand {

// my-sed 's/hello/world/' input.txt
// my-sed -e 's/hello/world/' input.txt
// my-sed --expression='s/hello/world/' input.txt

@Option(name: [.implicit, .short, .long])
var expression: [String]

@Argument()
var input: [String]

func run() throws {
print("expression: \(expression)")
print("input: \(input)")
}

}

MySed.main()
```

Help would show properties wrapped by ``@Option`` with an ``.implicit`` name specification into brackets
```
[[--expression] ]
```

They would, like ``@Argument``, be order dependent and face identical limitations when used on array properties.

Only one ``.implicit`` would be allowed by property (even on array properties)... in order to let simple in/out command line tools like

```
inout [-i] [-o]
```
process two files without ambiguity.

Start by locating how @Option name specifications are handled, then compare that behavior with @Argument for ordering, array limitations, and help rendering. Use the sed-style examples as the acceptance criteria; done means .implicit options support the documented forms and restrictions without ambiguity.

Written by the indexing model from the issue text.