Burn the batch context with fire

[kvark]

It can be used to save on mesh/program cloning (which have allocations!) when creating lots of batches. However, I'm convinced it brings more trouble than the benefit (#510, #464, #351). Besides, it can just be moved outside of gfx-rs crate.

The problem with the Context, outside of it just being another thing to consider or think about, is that it doesn't have a very safe interface. Thus, it could be fine to use inside another library as an implementation detail, but not fine to expose it to the user. I may end up moving it out and using it for gfx_scene, but I'll hesitate to do it until mesh/program cloning shows up in the profiler.

Let's burn this thing! We only really need a Batch trait and two kinds of batches: one with everything in it (batch::Full?), and another one with just the core components that have to be bound together (batch::Core). This is a breaking change supposedly for gfx-0.6

Objections? @csherratt @cmr @bjz

[milibopp]

I guess then gfx-rs would be unopinionated about how to share a resource. How does this work at the moment? I understand that e.g. a mesh is only a handle to a buffer on the GPU. What are its ownership semantics and when does it free the underlying resource?

[kvark]

@aepsil0n resources are reference-counted now anyway (they were not when Context was introduced), so they are shared. The only thing Context was providing is allocation-free copying of batches.

Since the mesh just has attributes pointing to GPU buffers, these get logically freed when the mesh goes out of scope (assuming it's the unique holder). The actual release call is done upon Device::cleanup(), typically right after the buffers swap.

[ghost]

This sounds good to me.

[kvark]

Fixed in #757