Clarify behaviour for using accessors outside commands

The WG made a clarification in 2020, but plan to revisit behaviour in SYCL Next.

> I think it should be possible to do better for SYCL Next, though. I _think_ this type of situation is what `erroneous behavior` is for. If we specified calls to these functions as `erroneous behavior` outside of commands, some implementations might be able to provide a compile-time diagnostic, some implementations might throw at runtime, but implementations wouldn't be permitted to do UB.

I agree. I said something similar in #580, but there were some concerns raised there about whether what we want _is_ "erroneous behavior" or just something similar to it.

Additionally, it looks like C++26 is going to introduce some new features and wording related to safety (e.g., hardened preconditions, contracts), so we may want to wait and revisit these sorts of issues after C++26 is finalized.

_Originally posted by @Pennycook in https://github.com/KhronosGroup/SYCL-Docs/issues/862#issuecomment-3047729988_

Start with the quoted WG clarification and the linked discussions in issues #862 and #580. Revisit the proposed erroneous-behavior approach alongside the C++26 safety and contracts wording; done means recording a settled specification clarification or documenting why the behavior remains deferred.

Written by the indexing model from the issue text.