Descripe the feature and motivation

We are trying to use mask type as the return type for comparison functions, and then some related functions like v_select, v_signmask, v_check_all/any can also be updated. As @alalek suggested in #22520

BTW, comparison functions and v_select() should work through dedicated masks type (vbool32_t in case of RVV) instead of the same data type.
This is old legacy design bug - comparison returns the same type as inputs type.
I believe it should be redesigned during adding of new "scalable" API.

For now, I start with RVV scalable backend, and here is a demo commit
Basically, I did the following in this patch:

1. Introduce a set of type about mask(boolean) type in RVV backend.

using v_float32_b = vbool32_t;
// v_float32_bis the new type in universal intrinsic
// vbool32_t is a built-in type in rvv.

2. Introduce the new type set for others backend, just an alias for the existing type for now.

#if !CV_SIMD_SCALABLE
    // Compatibility layer
typedef v_float32 v_float32_b;;
...

3. Rewrite the comparison functions and v_select functions (as the example)

// origin API
inline  v_float32 v_eq(const v_float32 & a, const v_float32 & b);
inline v_float32 v_select(const v_float32 & mask, const v_float32 & a, const v_float32 & b);
// new API
inline v_float32_b v_eq(const v_float32 & a, const v_float32 & b);
inline v_float32 v_select(const v_float32_b & mask, const v_float32 & a, const v_float32 & b);

4. Rewrite the usage in color_hsv.

This is just a demo commit to illustrating the necessary changes to use the mask type in RVV, and how it is compatible with other backends. I believe that this patch can be compiled for both RVV and other backends (AVX is tested).

After that, we may also need to modify the test cases and introduce specific mask types in other backends if they contain mask types and can benefit from them.

This proposal is still at a very early stage, any things including the implementation method, the naming of the type/functions, and even whether this redesign is needed are open for discussion, thanks in advance for any comments and suggestions!

Additional context

No response