Improve handling of extra characters on paired delimiters

[pokey]

The problem

Cursorless sometimes exhibits unexpected behaviour when handling paired delimiters. For example, in the following python code:

f"hello"

If the user says "twin repack harp", they are left with 'hello', rather than the expected f'hello'.

The solution

The primary problem here has to do with delimiters that can have optional leading or trailing characters. First, let's enumerate all known examples:

• $( in bash
• ${ in bash
• ${ in typescript
• f" in Python
• </ in HTML and jsx
• /> in HTML and jsx

To handle this case we'll make our delimiter representation a bit more structured. For both opening and closing delimiter, we'll support an object that has field for primaryCharacter, eg (, [ or ) and also fields for lists of optional leading / trailing characters, such as f, $, etc.

When searching for surrounding pairs, we'll include all forms of leading and closing, with or without trailing chars, in the regex / type matcher.

For all situations other than "repack", we'll just use the entire delimiter including any optional leading / trailing chars as the delimiter.

For "repack", the action itself (or potentially the target, if implemented on top of #210), will look at the text of the delimiter in the file, and check whether it includes optional leaders / trailers, and if so, see whether the new delimiter supports the same optional leading / trailing chars. If it does, it leaves the optional leader, otherwise removes. For example, saying "twin repack fine" for f"hello" will leave the f, but "square repack fine" would remove it

• Check that this work fixes /> for self-closing tags in JSX, where / and > are parsed as two separate tokens. In particular, / needs to be part of closing delimiter