If other plugins use `feedkeys` between the j and k presses, then the plugin breaks.

[Sam-programs]

Description

Assuming first_key is "j", second_key is "k", and timeout is infinite or (100000000000000),
When the user presses j, better-escape records "j" because it is a first_key.
Afterwards, if any other key that isn't a second_key is pressed, the plugin assumes the user pressed an unrelated key, so it deletes the recorded "j".
In the case that a plugin calls feedkeys, Better-escape detects that feedkeys call as the user pressing a key—if the plugin feedkeyed an unrelated key, better-escape deletes the recorded "j", and without the recorded "j", better-escape won't escape when k is pressed.
The case when a plugin calls feedkeys can be checked by reading the second paramater of vim.on_key —that used to be the case before #65 —but that paramater is only in nvim 0.10.0v+
I don't think that there is any other way to safely use vim.on_key. This isssue might have caused #68 since cmp might be using feedkeys with some configurations.

Example

User: presses "j"
Plugin: calls feedkeys("<cmd>foo<bar>")
User: presses "k" 
User stays in insert mode.

Repro

Install better-escape.
nvim +"so init.lua"

-- init.lua
vim.on_key(function(key) 
  if key == "j" then
    vim.api.nvim_feedkeys(vim.keycode("<cmd>w<cr>"), "in", false)  
  end
end)
vim.api.nvim_input("iSome textjk")

[max397574]

cmd is doing a lot of things using feedkeys which is a really questionable design imo

I think the only thing we can do about this is fix it for 0.10 users by using the second param of vim.on_key if it's available I guess?