Most of the old MD documentation files removed

docs/DESIGN.md

@@ -48,7 +48,7 @@ static_assert(10q_km / 5q_km == 2);
 
 The most important concepts in the library are `Unit`, `Dimension`, and `Quantity`:
 
-![Design UML](design.png)
+![Design UML](_static/img/concepts.png)
 
 `Unit` is a basic building block of the library. Every dimension works with a concrete
 hierarchy of units. Such hierarchy defines a reference unit and often a few scaled versions of
@@ -86,7 +86,7 @@ and `Ratio` is satisfied by any instantiation of `units::ratio<Num, Den, Exp>`.
 The `scaled_unit` type is a framework's private type and the user should never instantiate it directly.
 The public user interface to create units consists of:
 
-![Units UML](units.png)
+![Units UML](_static/img/units.png)
 
 All below class templates indirectly derive from a `scaled_unit` class template and satisfy a
 `Unit` concept:
@@ -620,7 +620,7 @@ User-friendly, short name printed by the compiler and the debugger.
 To fix it we have to provide a strong type. As we do not have opaque/strong typedefs
 in the language we have to use inheritance:
 
-![UML](downcast_1.png)
+![UML](_static/img/downcast_1.png)
 
 This gives us a nice looking strong type but does not solve the problem of how to switch from
 a long instantiation of a `derived_dimension_base` class template that was generated by the
@@ -636,7 +636,7 @@ specific base class template instantiation.
 
 Downcasting facility is provided by injecting two classes into our hierarchy:
 
-![UML](downcast_2.png)
+![UML](_static/img/downcast_2.png)
 
 In the above example `dim_area` is a downcasting target (child class) and a specific
 `detail::derived_dimension` class template instantiation is a downcasting source (base class).