The 1.2.152 headers add almost 300 VUs for Built-ins, most (if not all) of which I assume should be implemented in spirv-val

I created an initial PR to label all the current VUs in effort to know where to add effort in the battle for more complete Vulkan targeted SPIR-V validation

This issue is to address vk_validation_stats.py as I am willing to add the logic, but there a few a ways to go about it and wanted 2nd thoughts before I go off and create a PR as I realize there might be some internal flows I don't want to break on people.

1. Getting SPIR-V tools to scan source
   • One thought is that the script could attempt to clone the source ToT, only cloning the master branch in effort to reduce overhead
   • Another idea is just like the validusage.json to pass the path to a SPIR-V tools
   • Regardless, I feel this should work even if a user of the script
2. Marking where it the VU is implemented
   • Main issue is the VUID itself doesn't describe if it will be implemented in SPIR-V Tools or VVL until found in source
   • I imagine in the -summary it would be nice to show how many Explicit VUIDs of the total checked/tested are in SPIR-V tools repo
   • For the -html,-cvs, -text option it would be worth adding a column to describe if it is implemented in the Validation Layers or SPIR-V Tools
3. vk_validation_error_messages.h
   • There was some extra logic that was added to the ruby scripts in Vulkan-Doc to handle the fact these VUIDs belong to non-enum/commands/structs. I imagine there will need to be some extra logic for this file as well

Overall, I don't think this is too invasive of a change as it is all additive in nature