feat: Plugin support

[j-xella]

OK, maybe this is a wishful thinking which is waaaaaay out of what eza is supposed to do. But let me dream ....

Somehow, a plugin configuration is provided to eza that consists of these parts:

• long option name (must not clash with other names)
• optional, short option name (must not clash with other names)
• does option have a value?
• column header name
• executable name (and possible arguments) that accepts a list of file system objects on stdin (one per line, zero-separated ???) and for each file prints to stdout some info
• optional, what kind of file system objects this plugin can be applied to (files, folders, symbolic links, pipes, etc...)
• optional, timeout ?

Many plugins can be defined as above at the same time, as long as their names do not clash.

If user calls eza with short or long option name as defined above, then for each file system object eza calls the executable above, and prints the returned values in the appropriate column.

Now, obviously using plugins could take a performance hit, and users must be aware of it. But eza must try and minimize it:

• run several plugin executables in parallel, where possible. Maybe additional option for that, something like max-threads?
• re-use the same instance of running plugin instead of spawning new processes
• Start invoking plugins before all file system objects are read
• timeout on plugins after a while