This change removes the use of plenary's job API.
Whilst it has served us well up until now, there are several reasons why
it isn't well fit for Gitsigns and why a simpler implementation
will serve us better.
One of the key features of plenary jobs is that it provides on line
callbacks for reading stdout/stderr. Whilst these can be really useful,
they don't provide any benefits for Gitsigns which pretty much just
consumes the full output from all the processes it spawns. Additionally
the handlers are relatively complex and have been a source of problems.
These handlers also do a lot of processing by splitting data chunks and
searching for newline characters. This processing is wasted since we
concatenate the full output.
The new API simply returns two strings for stdout and stderr and it is
up to the caller on whether they need to split these into lines to
iterate over.
Plenary jobs were designed to be composed, chained together and
interrupted. To facilitate this, it has some fairly complex logic around
the uv pipe object handling to ensure they are correctly managed and
don't leak memory.
The new API simply opens the pipes, and closes them when the jobs
finish.
Plenary does a fair amount of input validation at runtime. While this is
useful for projects written in lua, since Gitsigns is implemented in
Teal, we can get all of these checks statically by implementing a job
API which is typed.
plenary.async requires several modules not used by gitsigns which is
inflating the startup time. Instead just require plenary.async.async.
On an M1 Macbook this appears to half the startup time of gitsigns.
