Figure out and enforce UR's "core" feature set

During discussion of #537 it came up that we don't have a well defined notion of optionality in the UR spec. A specific example of this is that due to how they're tested, the vast majority of the object handle queries are de-facto optional. This was a deliberate decision, and it's practical because we've always relied heavily on exterior testing rather than the cts for acceptance criteria. Now that we're looking to improve CTS coverage so that we can rely on it for acceptance we should also consider the optionality question in terms of how features are tested and how it's represented in the spec. It was suggested during the discussion that we could analyse the SYCL CTS and e2e tests to get an idea of what our core feature set should look like, and given the e2e tests are what we're trying to match in terms of coverage in the CTS that seems like a sensible place to start.

Start by examining the SYCL CTS and e2e tests referenced in the issue, then compare their coverage with the current UR spec. Define which features belong to the core set, decide how optionality should be represented, and determine how CTS coverage should enforce that decision.