Consider unterminated f-strings in FStringRanges (#8154)

## Summary

This PR removes the `debug_assertion` in the `Indexer` to allow
unterminated f-strings. This is mainly a fix in the development build
which now matches the release build.

The fix is simple: remove the `debug_assertion` which means that the
there could be `FStringStart` and possibly `FStringMiddle` tokens
without a corresponding f-string range in the `Indexer`. This means that
the code requesting for the f-string index need to account for the
`None` case, making the code safer.

This also updates the code which queries the `FStringRanges` to account
for the `None` case. This will happen when the `FStringStart` /
`FStringMiddle` tokens are present but the `FStringEnd` token isn't
which means that the `Indexer` won't contain the range for that
f-string.

## Test Plan

`cargo test`

Taking the following code as an example:

```python
f"{123}
```

This only emits a `FStringStart` token, but no `FStringMiddle` or
`FStringEnd` tokens.

And,

```python
f"\.png${
```

This emits a `FStringStart` and `FStringMiddle` token, but no
`FStringEnd` token.

fixes: #8065

crates/ruff_python_index/src/fstring_ranges.rs

@@ -5,8 +5,11 @@ use ruff_text_size::{TextRange, TextSize};
 
 /// Stores the ranges of all f-strings in a file sorted by [`TextRange::start`].
 /// There can be multiple overlapping ranges for nested f-strings.
+///
+/// Note that the ranges for all unterminated f-strings are not stored.
 #[derive(Debug)]
 pub struct FStringRanges {
+    // Mapping from the f-string start location to its range.
     raw: BTreeMap<TextSize, TextRange>,
 }
 
@@ -89,7 +92,6 @@ impl FStringRangesBuilder {
     }
 
     pub(crate) fn finish(self) -> FStringRanges {
-        debug_assert!(self.start_locations.is_empty());
         FStringRanges { raw: self.raw }
     }
 }