Add sycl_khr_group_interface extension

[Pennycook]

This extension introduces an alternative interface for groups of work-items, offering several improvements over the SYCL 2020 interface:

• Shorter names for member functions, dropping the get_ prefix.

• Cleaner separation between properties of a group (e.g., a group id) and properties of the calling work-item (e.g., its id within a group).

• Clearer distinction between "group" concept and "work_group" class.

• New work_item class to represent a single work-item within a specific parent group. This class also satisfies the group concept, modeling a group containing a single work-item.

[TApplencourt]

I like the usage of namespace.

    khr::work_group<1> g = ndit.get_group();
    khr::work_item it = get_item(g);

Few questions (sorry, trying to understand this new khr mechanism), should it be :

• khr::group_interface::work_item
• ndit.khr_group_interface_get_group? (or just ndit.khr_get_group()?)
• khr::group_interface::get_item?

[Pennycook]

I like the usage of namespace.

    khr::work_group<1> g = ndit.get_group();
    khr::work_item it = get_item(g);

Few questions (sorry, trying to understand this new khr mechanism), should it be :

• khr::group_interface::work_item
• ndit.khr_group_interface_get_group? (or just ndit.khr_get_group()?)
• khr::group_interface::get_item?

I don't think so. When vendors introduce extensions they use sycl::ext::vendor::, not sycl::ext::vendor::extension_name.

The way I see it, although putting something in the khr:: namespace reserves a name, the SYCL WG is in complete control over any names that are introduced there. Future extensions might have to be more creative with their naming, but there's no risk of surprise conflicts.