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

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.

Inizia individuando le API atomic_i_add e control_barrier e gli utilizzi mostrati nell’issue. Confronta le alternative con argomenti normali e con builder, incluso il modo in cui vengono composti i valori Scope e Semantics. Il lavoro è completato quando queste API non richiedono più i tre argomenti const-generic u32 e le chiamate mostrate rimangono utilizzabili con combinazioni leggibili di Semantics.