Add static constexpr members dimensions, access_mode and access_target to accessor class spec

[lbushi25]

This PR addresses #270. It follows in the footsteps of #351.
I think this will require CTS changes as well but I can't add the label myself.

[CLAassistant]

All committers have signed the CLA.

[keryell]

That looks like a good starting point.

[keryell]

For dimensions we could use mdspan equivalent https://en.cppreference.com/w/cpp/container/mdspan/extents/rank but unfortunately it relies on C++23 constexpr static access through this.

[gmlueck]

I think we should also add these static constexpr members to the other forms of accessors for consistency:

• host_accessor (section 4.7.6.10)
• local_accessor (section 4.7.6.11)
• unsampled_image_accessor and host_unsampled_image_accessor (section 4.7.6.13)
• sampled_image_accessor and host_sampled_image_accessor (section 4.7.6.14)

And also in these deprecated accessor specializations:

• The target::constant_buffer specialization (section 4.7.6.9.4.5)
• The target::host_buffer specialization (section 4.7.6.9.4.6)
• The target::local specialization (section 4.7.6.9.4.7)

[gmlueck]

Note that the sycl:: namespace is not strictly necessary here. It could be like this:

static constexpr access_mode access_mode = AccessMode;

But maybe the sycl:: is better for clarity anyway.

I was concerned at first that this definition of access_mode will shadow the type sycl::access_mode for any code inside this class. I think this will not affect the specification, though, because none of the member function parameter or return types use access_mode. Of course, implementations will likely need to change because they undoubtedly use the access_mode type in their implementations. I think that is OK, though. Raising the shadowing issue here, though, in case others see some problem.

[Pennycook]

I don't know if shadowing is a problem or not, but if it is then I think we already have it, because multi_ptr defines:

static constexpr access::address_space address_space = Space;

I'm just pointing that out because if we decide to do something different here, we may need to revisit multi_ptr.