optimization: use a DFA-based lexer for input

[knz]

First 3 commits from #568, #569 and #570.

This PR upgrades the map-based sequence detector to a lexical analyzer generated using golex.

The performance improvement is 4x, going down from from ~41.5ns/byte (using a map) to ~18.4ns/byte (using the DFA) on my test computer.

Informs #404.

[knz]

cc @muesli for your consideration. This is followup to what we were looking at yesterday. I'll add some benchmarks to showcase the improvement, even in the simple case when there is just 1 event in the input buffer.

[knz]

This is ready for review now.

[knz]

So right now this code consumes all the input coming from the terminal until there's a lull with no input, and then only it starts detecting events in the input data.

I wonder if that's the best approach. Don't we want the bubbletea model to start consuming events in parallel with the delivery of input bytes?

Also what if the input bytes are delivered continuously with no pause, or the go code becomes slowed down whereby there's always some input available in the input loop?

The alternative to this is to read the input incrementally as needed for each event, instead of doing it in two phases like previously. I'll try to prototype something.

[knz]

Note to self: also check the context cancellation during long reads.

[knz]

After discussion with @muesli we are considering the following:

• 1 PR to flip the control of readInputs to write the new messages to a channel directly.
• 1 PR to simplify the structure of readInputs while preserving the sequence map
• 1 PR to fix the long inputs
• 1 PR to use the golex-based sequence parser.

[knz]

I will need to adapt this after the control flow change in #569.