handle multiple 'open' paths with their correct handlers

[benmaddison]

Resolves #26

Currently, handlr open determines the mime-type and handler only for the first path in the list of arguments, and attempts to open all paths with that handler.

This corrects that behaviour by mapping each sub-set of the paths to the correct handler, and then launching each one.

@chmln, two open questions for you:

1. I have simply dumped the additional logic in main.rs as it didn't seem to fit naturally into either handler.rs or mime_types.rs. Let me know if you would like it somewhere else?

2. If any of the DesktopEntrys for the handlers have .term == true then the call to cmd.status() at: https://github.com/chmln/handlr/blob/37dae85b188e5e3815f09bfda0204bbbcc909e94/src/common/desktop_entry.rs#L51 will block, causing any further paths to be opened only after that process has exited.

   Thus if you do something like handlr open foo.txt bar.pdf (assuming the use of e.g. vim for .txt and zathura for .pdf), then vim will open foo.txt, and then zathura will open bar.pdf only once vim has exited. This seems to me to be undesirable, but I'm not certain what the correct behaviour should be:

   • Launch all handlers in a new terminal as if handlr didn't have a tty?
   • Defer Terminal=true handlers to the end of the list, so that non-terminal applications can launch with getting blocked?
   • Something else? Configurable?

Please let me have your thoughts when you get a gap.

[chmln]

Thanks for the PR @benmaddison Will take a look at this soon.

[chmln]

If any of the DesktopEntrys for the handlers have .term == true then the call to cmd.status() at:

I've changed this to spawn() as it doesn't make sense to block. Everything looks great and will be a part of v0.5.1 to be released soon