Make `Scope` and `Semantics` normal arguments rather than const generics

[nazar-pc]

The usage of atomics is quite awkward:

let position_in_bucket = unsafe {
    atomic_i_add::<_, { Scope::QueueFamily as u32 }, { Semantics::NONE.bits() }>(
        bucket_count,
        1,
    )
};

Not only one needs to know what each u32 is, it is not even consistent with the need to cast in one case and calling .bits() in another.

Similarly, barriers are awkward too:

control_barrier::<
    { Scope::Workgroup as u32 },
    { Scope::Workgroup as u32 },
    { Semantics::NONE.bits() },
>();

It is even worse when memory semantics is involved (though many of such cases have helper methods):

control_barrier::<
    { Scope::Workgroup as u32 },
    { Scope::Workgroup as u32 },
    {
        Semantics::WORKGROUP_MEMORY.bits() | Semantics::ACQUIRE_RELEASE.bits()
    },
>();

Subjectively, three u32s that need to be composed in a very particular way are quite ugly.

Consider changing API to use normal types for these arguments, so we can all enjoy autocomplete in IDE, better formatting and implement ability to combine semantics variants, like this:

let position_in_bucket = unsafe {
    atomic_i_add(
        bucket_count,
        1,
        Scope::QueueFamily,
        Semantics::None,
    )
};

control_barrier(
    Scope::Workgroup,
    Scope::Workgroup,
    Semantics::WorkgroupMemory | Semantics::AcquireRelease,
);

The result of Semantics::WorkgroupMemory | Semantics::AcquireRelease can be Semantics::Combined(u32) for example, with Debug implementation overridden to render human-readable set of enabled flags.

Alternatively, a builder pattern could be used for Semantics with const fn to have guarantees of sane composition in case some invariants fundamentally do not make sense.

At some point non-integer const generics will become available, but even then I see no benefit from const generics for this particular use case.