feat: Initial globbing ranges support

[vrongmeal]

We support two kinds of glob ranges:

• {N..M}: Here both N and M are valid integers and (N <= M).
• {str1,str2,str3}: Three different strings: "str1", "str2", "str3"

Example:

> select * from 'file_{2..3}.csv';
┌─────────┐
│ column1 │
│      ── │
│   Int64 │
╞═════════╡
│       2 │
│       3 │
└─────────┘
> select * from 'file{_1,_3}.csv';
┌─────────┐
│ column1 │
│      ── │
│   Int64 │
╞═════════╡
│       1 │
│       3 │
└─────────┘

[tychoish]

I was thinking about

• {0..a} and {a..0}
• what do we do for non-ascii alphabets?
• {3..} {r..}
• {..72}

We can imagine bounded ranges that only have an upper or lower bound working as long as the type/value being ranged over had a well defined collation. I initially thought that we'd only want to have unbounded ranges over bounded values, but because this is matching within a list of objects that we can iterate through, we could make it work. We don't have to support all of these now, but having tests that we can change later seems good.

There are also a bunch of potential syntax errors that we should produce clear error messages to users (and maybe this were the things that I thought might go in the enum:

• mismatched bracket types.
• wrong number of .. in glob
• mismatched start/end types

[vrongmeal]

Added more cases to handle the cases you mentioned.

I am not very keen on throwing an error since the "pattern" formation can be coincidental and we shouldn't throw an error until user opts-in or opts-out.

We definitely should have an "opt-out" from glob pattern so we can throw errors with confidence.

[tychoish]

some nits.

I'd also sort of like to see the tests also do BSON because the object store integration is a bit different, but I'm fine if we don't, I think.