Multiple attachment and multisample textures is broken and lacks robustness

[chaoticbob]

Issue stemming from #18

I looked at this a bit more and it seems like the move here maybe to better align TR's API with how DX works with multiple sample images. I played around with some changes which I'll put up on a branch later today.

High level list of changes:

• Added attachment parameter to tr_cmd_render_target_transition
• Added tr_cmd_resolve_image to resolve a single texture uses the format from single sample texture (not sure if this is the best thing)
• Added tr_cmd_resolve_render_target to resolve all attachments assuming their states are the same
• Removed the automatic resolve in tr_internal_dx_cmd_end_render

Here's what the function signatures look like:

tr_api_export void tr_cmd_render_target_transition(tr_cmd* p_cmd, tr_render_target* p_render_target, uint32_t attachment_index, tr_texture_usage old_usage, tr_texture_usage new_usage);

tr_api_export void tr_cmd_resolve_image(tr_cmd* p_cmd, tr_texture* p_src_texture, tr_texture_usage src_current_usage, tr_texture_usage src_final_usage, tr_texture* p_dst_texture, tr_texture_usage dst_current_usage, tr_texture_usage dst_final_usage);

tr_api_export void tr_cmd_resolve_render_target(tr_cmd* p_cmd, tr_render_target* p_render_target, tr_texture_usage ms_current_usage, tr_texture_usage ms_final_usage, tr_texture_usage ss_current_usage, tr_texture_usage ss_final_usage);

Let me know what you think.

[inequation]

Sorry for taking so long to respond! That looks great, thank you. :)