Gfx: Clarify TRANSFER_DST semantics with Dynamic usage and updates

[Bastacyclop]

Currently, the Dynamic usage is meant to express update capability and with it the TRANSFER_DST flag is not required but rather implied. Is this what we want, or should we require the flag to be set since updates are transfer operations ? In any case, this behavior should be clarified for the user and we should verify that gfx's code correctly takes it into account: for example the Bind::is_mutable method is currently inaccurate.
cc @kvark @eldyer

[Bastacyclop]

I think requiring the TRANSFER_DST flag for Dynamic updates would be more intuitive for both backend implementation and user. To get back some convenience, we could have buffer/texture builders (related to #1036) that would automatically add the TRANSFER_DST flag when specifying a Dynamic usage.
@msiglreith It would be nice to start introducing such builders along with corell.

[msiglreith]

In the current iteration, corell exposes heaps with associated properties (https://github.com/gfx-rs/gfx/blob/master/src/corell/src/memory.rs#L38-L63). The exposed heaps depend on backend and adapter (GPU).
This should offer the most flexibility for users, who want to deal with the low level API directly.

I would like to move the Dynamic, Data, Upload and Download usage indicators up into render, if possible, and combine them with the proposed builder pattern. The builder searches for the best heap available and also could set some additional flags (e.g TRANSFER_DST for Dynamic).

[Bastacyclop]

@msiglreith sounds good to me :)