Dynamically constructing a property_list?

Sometimes, the list of properties can only be known at run time.

Example: for a queue, we might enable or disable profiling with an env. variable, and also dynamically choose whether to use CUDA-style scheduling (in-order queues) or DAG-based scheduling (out-of-order queues). The code becomes:

```cpp
if (enableProfiling && inOrder)
{
return { sycl::property::queue::in_order(), sycl::property::queue::enable_profiling() };
}
else if (enableProfiling && !inOrder)
{
return { sycl::property::queue::enable_profiling() };
}
else if (!enableProfiling && inOrder)
{
return { sycl::property::queue::in_order() };
}
else
{
return { };
}
```

And to use SYCL_EXT_ONEAPI_QUEUE_PRIORITY, we would need to add one more level for `sycl::ext::oneapi::property::queue::priority_{high,normal,low}`.

With template metaprogramming, users can avoid explicitly writing all the branches, but having a standardized way to achieve the same would be nice.

Review the queue property construction example in the issue, including profiling, in-order scheduling, and SYCL_EXT_ONEAPI_QUEUE_PRIORITY cases. Define the scope of a standardized runtime property-list mechanism and confirm that it covers the combinations described without requiring manually written branches.

Written by the indexing model from the issue text.