Added support for custom image loaders

[schoentoon]

Took a bit longer than I expected. I ended up going for a whole interface around it, which you can implement yourself in any way you'd like.

[trashhalo]

@muesli since you are the first 3rd party consumer of this API could you review this PR to confirm it meets what your use case for glow?

[muesli]

I think I would have just gone for an io.Reader. That's all we need to load data. The wrappers for http / file loaders around it can be tiny then and we remove a lot of duplicated code.

[schoentoon]

Now that I look at it again I should probably have made the HttpImage accept a custom http.Client anyway. I mostly just figured that the file and http loaders were gonna be needed to keep the command line tool working anyway. So wouldn't make a huge difference whether it would be exposed in the library or just in the command line tool imo.

[muesli]

Understood. I'll quickly whip up an example with a simple io.Reader approach for comparison.

[muesli]

Here it is: #15

[muesli]

Just as a heads up: I skipped the other improvements @schoentoon introduced. Nice work there, I'm all for them!

[trashhalo]

@schoentoon You got some gnarly conflicts at the moment. For this to get merged. Changes I'd like to see:

1. Obvi conflicts addressed
2. Lib code moved back to root OR follow go standard layout

I have some bandwidth this weekend to push this forward if you are swamped.

[schoentoon]

TIL /lib is non-standard. I'll move it to /pkg later today and address the conflicts.

[muesli]

@schoentoon Yeah, it's all conventions, but I guess it makes sense to stick to the established ones. Sorry for causing the merge conflicts here, but I hope you can see why using the existing io.ReadCloser interface is sufficient in this case: it enables compatibility with an entire ecosystem of existing Go packages that all support this very interface (or the easily NilCloser wrapped io.Reader).

For this reason I think we should try not to introduce an ImageLoader interface here unless we got a really good reason for it.

[schoentoon]

I would argue that being able to provide a image.Image directly (or a gif.GIF for that matter) would be nice to have as well. Take for example wanting to apply certain filters over an image somewhere within your program. You'll probably already have a image.Image in such a case. Not having to encode it to later on decode it again seems like a benefit to me.