docs: titles added to some important admonitions

docs/users_guide/framework_basics/dimensionless_quantities.md

@@ -138,7 +138,7 @@ quantities deriving from them.
 As we observed above, the most common unit for dimensionless quantities is `one`. It has the
 ratio of `1` and does not output any textual symbol.
 
-!!! important
+!!! important "Important: `one` is an identity"
 
     A unit `one` is special in the entire type system of units as it is considered to be
     [an identity operand in the unit expression templates](interface_introduction.md#identities).

docs/users_guide/framework_basics/quantity_arithmetics.md

@@ -5,7 +5,7 @@
 If we think about it, the `quantity` class template is just a "smart" numeric wrapper. It exposes
 properly constrained set of arithmetic operations on one or two operands.
 
-!!! important
+!!! important "Important: `quantity` propagates the underlying interface"
 
     Every single arithmetic operator is exposed by the `quantity` class template only if
     the underlying representation type provides it as well and its implementation has proper
@@ -166,7 +166,7 @@ dimensionless kind.
 2. The resulting quantity of the LHS is `0 * dimensionless[h / min]`. To be consistent with the division
 of different quantity types, we do not convert quantity values to a common unit before the division.
 
-!!! important "Beware of integral division"
+!!! important "Important: Beware of integral division"
 
     The physical units library can't do any runtime branching logic for the division operator.
     All logic has to be done at compile-time when the actual values are not known, and the quantity types

docs/users_guide/framework_basics/text_output.md

@@ -66,10 +66,10 @@ The text output will always print the [value of a quantity](../../appendix/gloss
 typically followed by a space and then the symbol of a [unit](../../appendix/glossary.md#unit)
 associated with this quantity.
 
-!!! important
+!!! important "Important: Don't assume a unit"
 
-    Remember that when we deal with a quantity of an "unknown" `auto` type, it is a good practice
-    to always [convert the unit to the expected one](value_conversions.md#value-conversions)
+    Remember that when we deal with a quantity of an "unknown" (e.g. `auto`) type, it is a good
+    practice to always [convert the unit to the expected one](value_conversions.md#value-conversions)
     before passing it to the text output:
 
     ```cpp

docs/users_guide/framework_basics/the_affine_space.md

@@ -341,7 +341,7 @@ The following operations are not allowed in the affine space:
     - How to subtract a point on our trip to CppCon measured relatively to our home location from
       a point measured relative to the center of the Solar System?
 
-!!! important
+!!! important "Important: The affine space improves safety"
 
     The usage of `quantity_point` and affine space types in general, improves expressiveness and
     type-safety of the code we write.