Structuralization of captures

[milseman]

Structuralize matching engine captures, at least partially.

[milseman]

@rxwei I have a lot of tests cases in this PR if you'd like to take a look. I'm not entirely sure what behavior we want for all of them.

[rxwei]

Literal capture structure tests look good to me.

Did you plan to add DSL capture tests as well? For example, the following DSL

let regex = Regex {
    oneOrMore {
        capture("a")
        capture("b")
    }
} // `Regex<(Substring, [(Substring, Substring)])>`

is expected to produce Regex<(Substring, [(Substring, Substring)])> by the current design.

Unrelated to this PR: By the current DSL design, we'll have a .flatten() method which will be generated by the converter when converting literal (?:(a)(b))+.

let regex = Regex {
    oneOrMore {
        capture("a")
        capture("b")
    }.flatten()
} // `Regex<(Substring, [Substring], [Substring])>`

[milseman]

is expected to produce Regex<(Substring, [(Substring, Substring)])>

What is matchResult.1?

[rxwei]

[(Substring, Substring)]

[milseman]

@swift-ci please test linux platform

[natecook1000]

[rxwei]

Should this be deleted now that we don't need the VM?

[milseman]

CaptureTests uses this kind of functionality, but there it's hand-invoking the VM. We could delete it, unless it's useful for a match-API-based test. I was considering taking the legacy stuff out of the _StringProcessing module and put it back into the Prototypes module, at which point I believe this would move with it.

I'll follow up after this PR.