Instead of only extracting this for scoped completions using the AST, we
now extract the typed text for all requests in a uniform way directly
from the token stream.

This doesn't otherwise change any behavior.

This doesn't do any ranking or sorting, but it does filter our
completions by the text the user has typed so far.

We were already doing this for auto-import. For non-auto-import
completions, the number of symbols tends to be much smaller, so I don't
really expect this to result in any meaningful performance improvements.

This does mean our eval score gets a lot better, and indeed, the eval
reflects the real world more accurate since LSP clients do their own
filtering.

I had the logic flipped here, which resulted in `show-one`
not matching expected tasks in some cases. Basically, when
the `--file-name` and `--index` flags aren't given, then
the CLI should behave as if all file names and indices are
matched.

This is mostly a basic sanity test that we can return completions inside
of the interpolated segments of f-strings and t-strings.

This had been annoying me for a while: completions shouldn't
be offered inside of comments.

We detect this by looking for a `Comment` token before the
offset (with only `NonLogicalNewline` being allowed as an
intermediate token).

... except when we're in the interpolated segments of an f-string or a
t-string.

Previously, we would show completions for interpolated segments of an
f-string or a t-string. Which is good. But we did this by virtue of
never trying to suppress completions when in the non-interpolated part
of an f-string/t-string, or any other kind of string. Whcih is bad.

Here, we do our best to detect whether the cursor is within a string or
not. This seems somewhat straight-forward in the case of a string that
is properly opened/closed. But for a string that isn't closed
yet---which is likely common while typing---this is less
straight-forward. For the most part, I looked at some examples and tried
to reverse engineer the kinds of patterns we see in the token stream
when there is an unclosed string. It's likely not fully correct, but we
can improve it as we go.

Since `None` is a keyword, it isn't currently included in completions.
But this is a common papercut that is really annoying, and actually
makes typing `None` into the playground nearly impossible. So let's try
to fix this.

This doesn't implement fully context aware keyword completions, but it
does let us include the 3 keywords that are also values in completions.

This helps improve the completion experience when trying to write one of
these values in the ty playground.

Ranking could still be improved here. We haven't yet devised a mechanism
for ranking "builtin" symbols above others. It's even plausible that
these _particular_ symbols should get special treatment over and above
others.