refactor(core): replace convert_* wrappers with a member query

[JohelEGP]

Title: refactor(core): replace convert_* wrappers with a member query.

Description:

Replace

mp-units/src/core/include/mp-units/framework/customization_points.h

Lines 144 to 162 in 89bafed

	template<typename T>
	struct convert_explicitly {
	using value_type = T;
	T value;
	// NOLINTNEXTLINE(google-explicit-constructor, hicpp-explicit-conversions)
	constexpr explicit(false) convert_explicitly(T v) noexcept(std::is_nothrow_constructible_v<T>) : value(std::move(v))
	{
	}
	};
	template<typename T>
	struct convert_implicitly {
	using value_type = T;
	T value;
	// NOLINTNEXTLINE(google-explicit-constructor, hicpp-explicit-conversions)
	constexpr explicit(false) convert_implicitly(T v) noexcept(std::is_nothrow_constructible_v<T>) : value(std::move(v))
	{
	}
	};

with these members in the quantity-like-traits templates:

  static constexpr bool to_numerical_value_is_explicit = false;
  static constexpr bool from_numerical_value_is_explicit = false;

That removes the need to wrap and unwrap the numbers,
and simplifies the expressions in the explicit specifiers.

This will also require updating

• their use in the quantity templates,
• the std::chrono support,
• their own tests,
• any use in the examples, and
• the user guide documentation.

[mpusz]

Naming is hard 😉:

1. This does not control the convertibility to/from a numerical value, but to /from quantity/quantity_point. I do not have a good idea of how to rename this, though.
2. Should we mention "explicit" or "implicit" in the identifier?
3. Maybe we should be consistent with is_transparent and provide a type instead of the bool value instead?
4. Should both flags be true by default and not have to be provided in such case? Or should we always specify them and mandate this in a concept?

[JohelEGP]

Naming is hard 😉:

1. This does not control the convertibility to/from a numerical value, but to /from quantity/quantity_point. I do not have a good idea of how to rename this, though.

I'm still thinking.

2. Should we mention "explicit" or "implicit" in the identifier?

Explicit to avoid negations in the explicit specifiers.

3. Maybe we should be consistent with is_transparent and provide a type instead of the bool value instead?

That just makes the explicit specifiers harder to specify.

4. Should both flags be true by default and not have to be provided in such case? Or should we always specify them and mandate this in a concept?

I prefer explicitly requiring them.

[mpusz]

Maybe:

static constexpr bool to_quantity_is_explicit = false;
static constexpr bool from_quantity_is_explicit = false;

and

static constexpr bool to_quantity_point_is_explicit = false;
static constexpr bool from_quantity_point_is_explicit = false;

?

[JohelEGP]

The problem I have with that is that the "like" parameter is also a quantity (point).
So the direction is still confusing, "from our quantity, or their quantity?".

[mpusz]

You can also say that those also have some numerical value 😉
I could argue that that others are not "quantities" but duration or MyMetre. Unless it is about the cooperation with Au which uses proper names 😉

So maybe:

static constexpr bool explicit_import = false;
static constexpr bool explicit_export = false;

?

Naming is hard 😉