这次抽象，我几乎全盘否定了之前的抽象。
本来，RHI的抽象已经基本完成了，可以开心的写基础的光照阴影这些功能了。
但是，在QQ群里无意间看到大佬们聊起来bindless, 然后去查了查资料，发现bindless性能又好，抽象又好做，于是果断入bindless的坑。
在bindless抽象中，会把所有用到的材质参数，纹理全部放加载到显存，然后使用一个ID索引来引用相关的资源。
随着重构的进行，我发现之前的设计思路有很多问题，这都是因为我对GPU资源管理的不熟悉所致。
当我们向GPU上传纹理时或做更新资源时，由于GPU离CPU较远，所以Vulkan总是倾向于我们调用批量接口。
对！就像Nvidia说的那样，Batch! Batch! Batch!，但不仅仅局限于DrawCall, 转换内存布局，上传资源都需要Batch。
那么，此前做的所有抽象基本完全无用了。
在之前的抽象中，我都是基于同步的思路来做的，比如我new一个图片就需要等待他上传成功才能返回，不然结构体中的一些数据没有办法进行初始化。
经过仔细思考后，我认为此前提到的方案1其实是更好的选择。
数据冗余的问题也不难解决，只要我们把图形API层需要用到的数据下沉到图形API层的内部代码中，然后在RHI层的结构中做一个代理函数，通过gpu_handle来获取相关属性并返回即可。在实际应用中，由于width,height,format等属性属于低频访问，无论怎么封装，其实都不能成为性能瓶颈。
这样，新RHI层的数据结构只需要持有相应gpu_handle即可，这个结构有释放资源的责任。
比较微妙的是，由于bindless的存在，我们shader中的参数，如纹理，材质参数也都是通过id来索引的。
这样我们便直接把图形API层的资源管理透明掉了，RHI的数据结构可以直接和shader进行匹配，而不用关心图形API层是如何管理资源的。
透明掉图形API层之后，我们便拥有了更大的实现自由，比如在new rhi::texture2d时，图形API层只需要把上传到GPU时所需要的数据保存下来，然后分配一个gpu_handle, 函数就可以立即返回了。
在业务逻辑调用DrawCall之前，把需要用到的资源上传到GPU即可。
在实践中，由于DrawCall也是通过写入CommandBuffer中最终提交才异步执行的，因此我们只需要保证在CommandBuffer中，上传资源相关的GPU命令先于相关的DrawCall命令之前执行就可以了。
在Batch的指导思想下，其实使用gpu_handle的封装方式，能获得更好的Cache Friendly。因为所有图形API层的数据结构总是在渲染时，被批量访问。
而且，由于gpu_handle并不是指针，如果有需要还可以实现一些池的优化技术，如内存整理等（随着分配释放的进行，池中可能会有很多空位长时间用不到，这时出于内存和Cache Friendly的考虑，需要整理一个池中的元素的分布)。
最后，这次重构代码在此。
ps. 由于一些原因，可能未来很长一段时间内，这个引擎的Thread都需要换出了，先在这里保存一下上下文，以便后面可以继续换入
