intel/isl: Add a separate ISL_AUX_USAGE_HIZ_CCS_WT and ISL_AUX_USAGE_STC_CCS enums.

This is distinct between ISL_AUX_USAGE_HIZ_CCS and ISL_AUX_USAGE_HIZ_CCS_WT is that, when the HiZ surface operates in write-through mode which means that the HiZ surface is only used for depth-testing acceleration and the CCS-compressed main surface is always valid so we can texture from it.

Separating full HiZ from write-through mode at the isl_aux_usage level has a couple of advantages:

1. It's more explicit. Instead of write-through mode depending on the heuristic decision in isl_surf_supports_hiz_ccs_wt, it's now something that's explicitly requested by the driver. This should be more robust than hoping isl_surf_supports_hiz_ccs_wt always returns the same thing every time. If someone (say BLORP) ever drops a usage flag on the isl_surf, there's a chance it could return a different value without us noticing leading to corruptions.

2. Because ISL_AUX_USAGE_HIZ_CCS_WT is it's own isl_aux_usage flag, we can say inside the driver that HIZ_CCS does not support sampling but HIZ_CCS_WT does. We can also pass HIZ_CCS_WT to isl_surf_init_state and it can do some validation for us beyond what we would be able to do if we conflate HIZ_CCS_WT and CCS_E.

3. In the future, we can add new heuristics to the driver which do things such as start all depth surfaces (regardless of usage flags) off in HIZ_CCS and then do a full resolve and drop to HIZ_CCS_WT the first time it gets used by the sampler. This would potentially let us enable the faster HIZ_CCS mode even in cases where it technically comes in through the API as a texture.

Ideally, I think we'd like to play with 3, but this series does not do that. This series should have no functional change for iris. My primary motivation here is that I think the new ISL_AUX_USAGE makes more sense and would like to see it cleaned up before we implement HiZ+CCS for Vulkan.

The motivation for ISL_AUX_USAGE_STC_CCS is that stencil CCS is slightly different from color CCS. Using a color CCS resolve with stencil CCS doesn't do the right thing and you can't sample from a stencil CCS image without the DepthStencilResource bit set or you will get the wrong data. Stencil CCS also has it's own rules such as it doesn't support fast-clear and has no partial resolve. This seems to indicate that it should probably be its own isl_aux_usage. Now that adding new isl_aux_usage values is pretty cheap, let's split stencil CCS out on its own.

The crowning patch of this MR changes the way we set the DepthStencilResource bit in RENDER_SURFACE_STATE to treat it as an extension of AuxiliarySurfaceMode. This goes a bit outside of the way the docs are written but seems to be in better alignment with what the bit actually means in hardware.