define keys on RegexMatch

[oxinabox]

This came up in discussion in #34355
Seperating it out from that PR because it is a far less clear question/answer.

In general if we define getindex we should define keys.

Some things in this PR you might take issue with:

### 1. It returns a tuple. `keys` only promises that it will return a iterator. `keys` on a `NamedTuple` returns a `Tuple`, `keys` on a `Vector` returns a `OneTo`. A `Tuple` just seems like the simplest thing to do this will normally be small so i didn't think some kind of `KeySet` would be appropriate also the keys *are* infact ordered, just like the are for a `NamedTuple`.

2. It returns a mix of named and number keys.

We can't return all named since they might not all be named.
We could return all numbered, I would be down with that.
Very easy PR. keys(m::RegexMatch = keys(m.captures).

It seems like this is what we want since this is what show currently displays.

[oxinabox]

3. in consistent with haskey

If combined with #37300 we do end up with a similar problem to what we currently have for NamedTuples where haskey and keys disagree with each other.
haskey(nt, 1)==true but 1 in keys(nt)==false (if the first capture group was named)

One way to resolve this would be with a special object that overloads in to accept both.
Should that be done?
Doing that would make us less consistent with NamedTuples however.

[KristofferC]

Tuple just seems like the simplest thing to do this will normally be small so i didn't think some kind of KeySet would be appropriate

Is it really simpler than e.g. a Vector{Union{Int, Symbol}}? If you have a function that you send these keys into, it will specialize for all permutations of Symbol and Int you pass in, which is perhaps not what you want.

[oxinabox]

Is it really simpler than e.g. a Vector{Union{Int, Symbol}}?

No it isn't.
I meant that it is simpler than defining a new KeySet like type.
Definately could change to returning a Vector.

[KristofferC]

I meant that it is simpler than defining a new KeySet like type.

I guess the advantage is that with a KeySet like type you don't need to allocate?

[JeffBezanson]

This is a good feature, but I definitely think it should not return a tuple. A Vector would be fine. The tuple version is type-unstable, and I doubt you would ever want code specialized on this.

[JeffBezanson]

Please fix test and rebase.

[oxinabox]

I thought this was merged ages ago.
Can we merge it so it stops accumulating conflicts?

[oxinabox]

Bump

[oxinabox]

Bump.
As far as I know noone has voiced any objection to this feature in the 6 months this PR has been open.
Other than using a Vector rather than a tuple which has beeb resolved also for about 6 months.
Is there anything at all i need to do or see resolved?