cleaning up new id system a bit

I think the errors that arose from PR #2458 indicate the way the new id system is setup is too error prone to code. Is there any reason why the ID isn't a struct with the id number, level number as separate variables, and have the maps/sets that use the ID be keyed with that struct type instead? It seems like it would be much less error prone than all the bitshift/or/anding that is going on which is easy to forget to do at each usage point. It's not like it's saving any memory.
Or, if we want to stay lower level, a union between a int64_t and a set of bit fields, so it's easier to access the different sections of the int64_t without needing to remember shifting etc when wanting different types of data out of the id.
I'm happy to do the changes if there are no objections.

Thoughts? @johnkslang @ShchchowAMD @greg-lunarg

Start by reading PR #2458 and tracing the new ID system's bit-shift, OR, and AND usage in maps and sets. Confirm the representation choice with maintainers, then consider the work complete when the agreed ID representation is applied consistently and addresses the errors that motivated this issue.

Written by the indexing model from the issue text.