Canvas::set_target is actually unsound

[Cobrand]

cc @nrxus

I made an article last week about our experience trying to refactor SDL2's render part, which you can see here. The article was very well, however a certain Ralf sent me an email with a very interesting statement:

However, I am slightly concerned about your with_target at the end of the post. It seems to me like this suffers from the same problem that thread::scoped already ran into, namely -- Rust does not prevent memory leaks, and as a result, the destructor is not guaranteed to run. Specifically, what happens if someone calls mem::forget(canvas.with_target(tex))? Maybe I am missing something, but it seems to me like this would leave the canvas in a bad state.

rust-lang/rust#24292
https://github.com/rust-lang/rfcs/blob/master/text/1066-safe-mem-forget.md

And he was totally right: if you mem::forget the TextureCanvas, the old canvas will render to a Texture instead of a Window... this would have been a minor problem if it was actually sound, but it isn't; now that TextureCanvas is dropped, the texture can be used freely again, including being able to render on itself (never tried, but sound like a terrible idea), and being dropped itself, leading to the texture being targeted by the Canvas internally actually being freed, but still being targeted for draws and such.

The solution here is to actually give a closure as a parameter of with_target, allowing us to control in 100% of the cases when to reset the target. The inconvenient part is that it would be more annoying to use, but it's the price to pay for safety, unfortunately.

[RalfJung]

Seems I was too slow to open this issue myself. Whatever, the fix looks good :)