Questions regarding the identity of SYCL runtime classes.

I feel that the current (rev. 5) SYCL 2020 specification is a bit vague when it comes to the identity of the runtime classes (`platform`, `context`, etc.). Let us start with the `platform` class. The specification says (p. 21):

> A platform can be viewed as a given vendor’s runtime and the devices accessible through it.

So initially I would assume that (for example) oneAPI would give me a platform that is associated with all the Intel GPUs, CPUs and FPGAs built into the system. However, `platform`'s constructor takes a device selector as parameter (unless I use the default ctor). So, on a system where oneAPI is the only SYCL implementation - what happens here?

```c++
auto p1 = sycl::platform{cpu_selector_v};
auto p2 = sycl::platform{gpu_selector_v};

p1 == p2; // true or false?
```

Another question is what will happen if I construct two platforms that take the same selector:

```c++
auto p3 = sycl::platform{cpu_selector_v};
auto p4 = sycl::platform{cpu_selector_v};

p3 == p4; // true or false?

auto v3 = p3.get_devices();
auto v4 = p4.get_devices();

v3 == v4; // true or false? Are v3 and v4 ordered in the same way?
```

This also applies to the `context` class. Will two contexts that take the same list of devices be identical? Can I share memory objects between them?

```c++
auto c1 = sycl::context{v3};
auto c2 = sycl::context{v3};

c1 == c2; // true or false?
```

I hope I didn't miss the part in the specification where this is cleared up.

Read the SYCL 2020 specification around page 21 and the sections defining platform and context. Compare the stated behavior of constructors, equality, device lists, ordering, and memory sharing with the questions and examples in the issue. Done means the specification clearly defines these identities and relationships.

Written by the indexing model from the issue text.