Image editing should not require a giant pile of vendored JS

[lewiscollard]

After #12, which will put image editing on a separate form, it might be best to not have our own copy of the TUI image editor. Maintaining this in-tree seems like effort,

For sites with a strict Content Security Policy, it might be best to supply either an override URL for the image editor JS, and also to disable image editing altogether.

The vendored JS and the entire old image editor has been deleted. See the next comment.

[lewiscollard]

And on second thoughts, I wonder whether the "pile of JS in the browser doing image editing operations and posting image data to the server" is the right thing.

What do we actually want to do? Currently, the editor in its default configuration gives you

• cropping
• rotation
• flipping

...and that's it. Is it reasonable to say "if you want more than that, load it into a real image editor"?

Because if those operations are all that is needed...then we don't even need a giant pile of JS for that. In fact, we don't have to do any image data editing in the browser at all. We can have a little bit of JS and CSS which simulates the operations that will be done. The operations that are sent back to the server can be like "crop=xxx&rotate=yyy&flip=zzz" and do that all on the server side. (as a bonus it's only a tiny leap from there to making image editing work with no JavaScript...)

The big downsides to the current approach are a) it requires megabytes of JavaScript b) the image degradation is noticeable between edits c) it can only send back uncompressed 32-bit PNG data to the server - with full-res photos from digital SLRs it can and does exceed a 20 megabyte DATA_UPLOAD_MAX_MEMORY_SIZE.