Allow to enable half and bfloat16 at the same time

[yhmtsai]

This PR allow to enable bfloat16 and half precision at the same time.
Doing the operation between bfloat16 and half precision returns float type.
It will revert the gko::float16 alias changes in #1825 . float16 will be half precision again.
Moreover, it adds the next_precision_move<type, move> to represent the next_precision<next_precision<.... same for previous_precision_move

likely in another PR:

• convert_to are just copy the same implementation for different interface. create a templated convert_to in private: and convert_to always call the templated function
• instantiation macro, which we might apply the same technique as what I did in batch to use nested structure
• allow run<> to accepts type_list and create a list for that

[MarcelKoch]

Some first notes, I still have to finish the rest of the PR. However, I think these are already the most relevant comments.

[MarcelKoch]

maybe combine this with the move version as

template<typename T, size_t step = 1>
struct next_precision_impl{...};

Then we don't need to use both next_precision and next_precision_move. As an example see: https://godbolt.org/z/dPK7ccxoM

[yhmtsai]

good to know tuple_element_t. I will change it to yours.

[MarcelKoch]

nit:

Suggested change

	using NextNextDense = matrix::Dense<next_precision_move<ValueType, 2>>;
	using NextNextNextDense = matrix::Dense<next_precision_move<ValueType, 3>>;
	using Next2Dense = matrix::Dense<next_precision_move<ValueType, 2>>;
	using Next3Dense = matrix::Dense<next_precision_move<ValueType, 3>>;

[MarcelKoch]

Should we perhaps always have these ConvertibleTo base classes? Right now, we always provide the gko::half and gko::bfloat16 classes, so the ConvertibleTo variants are valid. It only requires making the gko::array fp16 conversion functions available, which is a very manageable cost compared to the full fp16 build.
From the user perspective, using (any) fp16 only breaks when they try to instantiate one of our classes. So they will not be able to use the conversion function with fp16 anyway.
I should note that the error will be a linker error, which is most likely very painful for the users to decipher.

[yhmtsai]

ConvertibleTo that class needs to instantiate the class then the member function will require the function all available.
We do not go the same way to deal with the dpcpp single (throw not_implment) because the current macro design to change that with the three conditions (single/half/bfloat) will be a disaster. also, I guess it will exceed the symbol limit in windows

[MarcelKoch]

I might have not communicated exactly what I meant, so I will create a PR to illustrate. In short, I think the #if guards for the ConvertibleTo are unnecessary.

[MarcelKoch]

Looks mostly good. My comment on the ConvertibleTo stuff can be ignored for this PR.

[MarcelKoch]

I think this needs to be guarded.

[yhmtsai]

It only gives some redundant check with the fixed *_move template.
The code using the redundant part means nothing matched here, so it will throw the error in the end.

[MarcelKoch]

shouldn't it be

Suggested change

	typename U = typename next_precision_impl<T>::type>
	typename U = typename next_precision_impl<T, move>::type>

[yhmtsai]

no, it is just to start the search from the next one.
The stop criterion of recursion is when the searching U is the same type as T.
It might jump to much for example <half, 2> in <half, float, double>, the search will only check double, half (stop) without considering float.