[SYCL][Doc] Simplify non-uniform group design

[Pennycook]

This commit simplifies the design of the non-uniform group extension as follows:

• The _group suffix is removed from user-constructed groups to reduce verbosity.

• get_*_group() functions are replaced with partitioning functions, to clarify that users are not getting an existing group but rather creating a new one.

• Fixed-size groups are renamed to "chunks". The previous name did not convey that the group is contiguous as well as having a fixed size.

• Ballot-groups and opportunistic-groups have been combined into a single group type called a "fragment", focusing on what the groups represent rather than how they were constructed.

• Synchronization behavior is added to all partitioning functions, to reduce the cognitive burden (of remembering which partitioning functions synchronize).

• An implicit cast from chunks to fragments is introduced. A fragment is a more general representation than a chunk, and so this conversion is always valid.

• Split tangle into its own extension. The implementation requirements for tangle are different to other non-uniform groups, which may limit their availability to certain device types. Splitting them out into a separate extension will make it easier to set user expectations and to track implementation status across backends.

[AlexeySachkov]

Haven't looked at the tangle doc yet

[AlexeySachkov]

We should probably update linear_id_type definition here, see the discussion about recorded inconsistency in #13702. Linear id type is smaller than chunk size, meaning that in certain cases we won't be able to enumerate all work-items in a chunk.

[Pennycook]

I see a few possible fixes here and I'm not sure what is best:

1. linear_id_type = std::size_t
   Always matches, no problems.

2. linear_id_type = ParentGroup::linear_id_type
   Sets uint32_t for sub_group and size_t for group. The situation where somebody provides a ChunkSize larger than the ParentGroup would prevent enumeration of all work-items in the chunk, but that situation is already UB.

3. linear_id_type = /* smallest unsigned integer with log2(ChunkSize) bits */
   Could use std::uint8_t for ChunkSize < 256. Might lead to future ABI issues if we get something like a std::uint4_t in future (but that seems unlikely, given the number of bits in a byte).

[AlexeySachkov]

I lean towards (2) here, because it makes chunk consistent with its parent group. I.e. if someone had a code for sub-groups, but then introduced some specialization for chunks, types of all IDs they may have in use would still match what APIs return. And this will also be true when we extend chunks to support group.

[Pennycook]

Makes sense to me. I made the change in 0f2a471.

[AlexeySachkov]

tangle part review

[AlexeySachkov]

All my feedback has been addressed, I don't have any further comments. That issue about liner_id_type of chunk is not a high-priority one to be resolved immediately, because we don't have a device which supports sub-group sizes bigger than uint32_t and potential issue I've highlighted there can't really be encountered right now.

[AlexeySachkov]

@intel/dpcpp-specification-reviewers, any further comments before I merge this PR?

[AlexeySachkov]

@intel/dpcpp-specification-reviewers, any further comments before I merge this PR?

I treat lack of response as a no, so merging the PR