Render images with image.nvim

[benlubas]

this will stay in draft state until todo items are done

The What

image.nvim is a NeoVim plugin that adds image support. This PR uses the plugin like a library to render image outputs.

This PR also incorporates some performance improvements that were proposed in #43, with a few bugs ironed out.

The Why

1. Consistency. Before, we had our own image implementations. There was a kitty graphics image implementation, and an uberzug image implementation. I never used uberzug, but the kitty implementation was inconsistent at best, and buggy at worst for me. I've found image.nvim's implementation to be very solid, and the maintainer very interested in fixing bugs that I've brought up.

2. Maintainability. Handling our own image rendering is far less maintainable than simply outsourcing the heavy lifting to another plugin.

3. Image.nvim has sixel support on the road map. I'm not sure if/when that'll be, but we'll get it for free if it even happens.

Considerations

• Image.nvim is very new, and subject to change. The API that we're using might change. Modern package managers can pin versions, so I'm not too concerned. But this is still something to watch out for.

• I've just ripped out the old image backends, but it might be worth to keep them in with a deprecation notice for a month or so to let people migrate to image.nvim without everything breaking right away.

todo

• Merge the other changes this PR includes. Currently this PR contains changes that are proposed in Feat: magma_enter_output_behavior #112 feat: MagmaHideOutput command #110 and MagmaEvaluateRange vim function #109
• waiting on an image.nvim api update adding cropping functionality to fix a bug where images display over the status bar
• Update the README
• about a week or two of testing this in action
• possibly add old image providers back, keep them in with a deprecation warning for a month or so
• round one of bug fixing

[benlubas]

I think I'm just going to close this PR out, and maintain a fork of this plugin under a different name.

I don't want to bother others with an excessive number of PRs, and I'd like to make many large and some breaking changes to improve the plugin. I think it's best to just work in my own repo.