feat: refactor dtypes as objects, add constants

[nicola-bastianello]

this PR refactors dtypes as objects; in particular:

• it defines a new custom object dtype instantiated as dtype("float32"), with properties name, available and backend_dtype. backend_dtype is bound to the corresponding backend dtype object at set_backend, and any dtype created afterwards is also bound
• two dtypes are the same if they are both available and have the same name
• Backend now exposes one property for each of the supported dtypes; the property is abstract if the dtype is supported by all frameworks, non-abstract and returning None otherwise. subclasses of Backend return a native dtype object if available, None otherwise
• functions involving dtypes were refactored to use dtype objects
• to access the dtypes: from decent_array import float32
• the user guide was updated to discuss dtypes; dtype object is documented but the dtype instances are not in the API reference

other changes:

• added constants e, pi, inf, nan as aliases of the framework-native constants (after set_backend is called, before they alias the corresponding math constants). to get the constants: from decent_array import e
• constants are also abstract properties of Backend that need to return the framework-native constants
• renamed SupportedFrameworks, SupportedDevices, SupportedArrayTypes by removing "supported". I personally find them easier to read this way since the names start differently, but I'm open to discuss
• added a private module _utils.py to store unwrap, which was redefined in several places

the dtype refactor has the following benefits:

• it aligns with all frameworks, which also define custom dtype objects (and with the array api as well)
• it allows to define dtypes/constants as properties of Backend, ensuring that we handle them in the same way as all other framework-native items
• it allows to mark dtypes as available or not, since not all dtypes are available in all settings (factors that impact availability are framework, framework settings, OS, device). this can be expanded in the future to do programmatic checks of what is available in each framework (e.g. by running a test operation and catching errors; in most frameworks there is no other way to check availability)
• it is more user friendly, as one just does dtype("float32")

closes #8