Add storage images

Add class hierarchy images to storage user APIs.

Author: AnotherButler

docs/reference/api/storage/ChainingBlockDevice.md

@@ -1,5 +1,7 @@
 ## ChainingBlockDevice
 
+<span class="images">![](https://os.mbed.com/docs/v5.8/mbed-os-api-doxy/class_chaining_block_device.png)<span>ChainingBlockDevice class hierarchy</span></span>
+
 The ChainingBlockDevice class provides a way to chain together multiple block devices. You can then interact with the chained block devices as if they were a single block device of size equal to the sum of each substorage unit. The ChainingBlockDevice acts as an opposite of the [SlicingBlockDevice](/docs/v5.8/reference/slicingblockdevice.html).
 
 Note that each block device's block size must be a multiple of the other devices' block sizes (512, 1024 and so on).

docs/reference/api/storage/HeapBlockDevice.md

@@ -1,5 +1,7 @@
 ## HeapBlockDevice
 
+<span class="images">![](https://os.mbed.com/docs/v5.8/mbed-os-api-doxy/class_heap_block_device.png)<span>HeapBlockDevice class hierarchy</span></span>
+
 The HeapBlockDevice class provides a way to simulate block devices for software development or testing. The created blocks are nonvolatile; they do not persist across power cycles.
 
 HeapBlockDevices have the following configurable parameters in either one of two constructors:

docs/reference/api/storage/LittleFileSystem.md

@@ -1,5 +1,7 @@
 ## LittleFileSystem
 
+<span class="images">![](https://os.mbed.com/docs/v5.8/mbed-os-api-doxy/class_little_file_system.png)<span>LittleFileSystem class hierarchy</span></span>
+
 The little file system (LittleFS) is a fail-safe file system designed for embedded systems, specifically for microcontrollers that use external flash storage.
 
 ```

docs/reference/api/storage/MBRBlockDevice.md

@@ -1,5 +1,7 @@
 ## MBRBlockDevice
 
+<span class="images">![](https://os.mbed.com/docs/v5.8/mbed-os-api-doxy/class_m_b_r_block_device.png)<span>MBRBlockDevice class hierarchy</span></span>
+
 The MBRBlockDevice class provides a way to manage a Master Boot Record (MBR) on a storage device, which allows you to partition the device. Without the MBR, you can still format a storage device with a file system, but including the MBR will allow for future partition modifications.
 
 MBRBlockDevices have the following configurable parameters in the constructor:

docs/reference/api/storage/ProfilingBlockDevice.md

@@ -1,5 +1,7 @@
 ## ProfilingBlockDevice
 
+<span class="images">![](https://os.mbed.com/docs/v5.8/mbed-os-api-doxy/class_profiling_block_device.png)<span>ProfilingBlockDevice class hierarchy</span></span>
+
 The ProfilingBlockDevice class provides a decorator for an existing block device object to log reads, writes and erases.
 
 ProfilingBlockDevices take in a pointer to the block device being profiled as the only configurable parameter. If you want to count a storage operation such as programming, reading or writing to a block device, you should use the ProfilingBlockDevice object as the interface to the storage block rather than the underlying device. The below example highlights this use case.

docs/reference/api/storage/SlicingBlockDevice.md

@@ -1,5 +1,7 @@
 ## SlicingBlockDevice
 
+<span class="images">![](https://os.mbed.com/docs/v5.8/mbed-os-api-doxy/class_slicing_block_device.png)<span>SlicingBlockDevice class hierarchy</span></span>
+
 The SlicingBlockDevice class provides a way to break up a block device into subunits without the need to manually track offsets. The SlicingBlockDevice acts as an opposite of the [ChainingBlockDevice](/docs/v5.8/reference/chainingblockdevice.html) class.
 
 The constructor takes in the master block device pointer and the start and end addresses of where you would like to partition the sub-block. By not specifying the end address, you create a block device that spans from the provided start address to the end of the underlying block device.