This PR combines a couple of optimizations to drastically reduce the
time it takes to gather everything necessary for rendering Alacritty's
terminal grid.

To help with the iteration over the grid, the `DisplayIter` which made
heavy use of dynamic dispatch has been replaced with a simple addition
to the `GridIterator` which also had the benefit of making the code a
little easier to understand.

The hints/search check for each cell was always performing an array
lookup before figuring out that the cell is not part of a hint or
search. Since the general case is that the cell is neither part of hints
or search, they've been wrapped in an `Option` to make verifying their
activity a simple `is_some()` check.

For some reason the compiler was also struggling with the `cursor`
method of the `RenderableContent`. Since the iterator is explicitly
drained, the performance took a hit of multiple milliseconds for a
single branch. Our implementation does never reach the case where
draining the iterator would be necessary, so this sanity check has just
been replaced with a `debug_assert`.

Overall this has managed to reduce the time it takes to collect all
renderable content from ~7-8ms in my large grid test to just ~3-4ms.

Fixes #5041.

Fixes #4879.

Co-authored-by: Christian Duerr <contact@christianduerr.com>

Previously Alacritty was using two different ways to reference lines in
the terminal. Either a `usize`, or a `Line(usize)`. These indexing
systems both served different purposes, but made it difficult to reason
about logic involving these systems because of its inconsistency.

To resolve this issue, a single new `Line(i32)` type has been
introduced.  All existing references to lines and points now rely on
this definition of a line.

The indexing starts at the top of the terminal region with the line 0,
which matches the line 1 used by escape sequences. Each line in the
history becomes increasingly negative and the bottommost line is equal
to the number of visible lines minus one.

Having a system which goes into the negatives allows following the
escape sequence's indexing system closely, while at the same time making
it trivial to implement `Ord` for points.

The Alacritty UI crate is the only place which has a different indexing
system, since rendering and input puts the zero line at the top of the
viewport, rather than the top of the terminal region.

All instances which refer to a number of lines/columns instead of just a
single Line/Column have also been changed to use a `usize` instead. This
way a Line/Column will always refer to a specific place in the grid and
no confusion is created by having a count of lines as a possible index
into the grid storage.

This refactors a large chunk of the alacritty_terminal API to expose all
data necessary for rendering uniformly through the `renderable_content`
call. This also no longer transforms the cells for rendering by a GUI
but instead just reports the content from a terminal emulation
perspective. The transformation into renderable cells is now done inside
the alacritty crate.

Since the terminal itself only ever needs to know about modified color
RGB values, the configuration for colors was moved to the alacritty UI
code.

Fixes #4687.

This fixes up all of the remaining enums which are used in the
configuration file to make sure they all support fully case insensitive
deserialization.

Fixes #4611.

This resolves an issue with Alacritty's scrolling region performance
when there's a number of fixed lines at the top of the screen. This
affects commonly used applications like tmux or vim.

Instead of using separate logic for when the scrolling region starts at
the top of the screen without any fixed lines, the code should now try
to figure out the target position of these fixed lines ahead of time,
swap them into place and still perform the optimized implementation to
move the grid.

This comes with the small trade-off that since lines are swapped before
rotating the screen without clearing or removing any lines during the
rotation process, that the places the fixed lines have been swapped with
will appear out of order when using scrolling regions in the primary
screen buffer. Since the use of scrolling regions primarily affects the
alternate screen and most terminals don't keep any history at all, this
should however not cause any problems.