MoltenVK Vulkan 1.0: Metal shares binding count for constant buffers (uniform buffers) and device buffers (storage buffers)

Failing CTS test:
```
dEQP-VK.pipeline.monolithic.descriptor_limits.compute_shader.uniform_buffers_31
```

Vulkan provides `VkPhysicalDeviceLimits::maxDescriptorSetUniformBuffers` and `VkPhysicalDeviceLimits::maxDescriptorSetStorageBuffers` which lets the user know how many uniform/storage buffers (respectively) can be bound per stage. However, Metal has a shared binding count for both uniform (constant) and storage (device) buffers.

Now, MoltenVK sets both `VkPhysicalDeviceLimits::maxDescriptorSetUniformBuffers` and `VkPhysicalDeviceLimits::maxDescriptorSetStorageBuffers` to the maximum value Metal provides for buffer bindings. This is an issue because if the user decides to max uniform bindings (for example), and then bind one storage buffer, the storage buffer will go out of the allowed binding range for buffers leading to an error. This is what happens in the test.

A few potential approaches to fix the issue come to mind:
1. Assign values to `VkPhysicalDeviceLimits::maxDescriptorSetUniformBuffers` and `VkPhysicalDeviceLimits::maxDescriptorSetStorageBuffers` such that the addition of both does not go beyond what Metal allows.
2. Create a flag in the portability extension to let the user know the amount of buffer bindings are allowed, both uniform and storage in total.
3. Request a waiver (not my preference).

Let me know if I missed something that would render my conclusion obsolete. Let me know if there's a preferred approach for the issue.

Start with the failing CTS test dEQP-VK.pipeline.monolithic.descriptor_limits.compute_shader.uniform_buffers_31 and review the interaction between the two VkPhysicalDeviceLimits buffer counts and Metal's shared buffer-binding limit. Compare the three approaches listed in the issue, then define the selected behavior and verify that the CTS test no longer fails.

Written by the indexing model from the issue text.