Update mbed_targets.md

Fix header sizes

Author: Amanda Butler

docs/advanced/mbed_targets.md

@@ -25,11 +25,11 @@ The style that we use for targets is:
  - Lists take up at most one line.
  - Long lines are not split.
 
-# Standard properties
+## Standard properties
 
 This section lists all the properties the mbed build system understands. Unless specified otherwise, all properties are optional.
 
-## `inherits`
+### `inherits`
 
 The description of an mbed target can "inherit" from one or more descriptions of other targets. When a target, called a _child_ inherits from another target, called its _parent_, the child automatically copies all the properties from the parent. After the child has copied the properties of the parent, it may then overwrite, add or remove from those properties. In our example above, `TEENSY3_1` inherits from `Target`. This is the definition of `Target`:
 
@@ -75,21 +75,21 @@ Avoid using multiple inheritance for your targets. If you use multiple inheritan
 
 For more details about the Python method resolution order, check [this link](http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path).
 
-## `core`
+### `core`
 
 The name of the target's ARM core.
 
 Possible values: `"Cortex-M0"`, `"Cortex-M0+"`, `"Cortex-M1"`, `"Cortex-M3"`, `"Cortex-M4"`, `"Cortex-M4F"`, `"Cortex-M7"`, `"Cortex-M7F"`, `"Cortex-A9"`
 
-## `public`
+### `public`
 
 The `public` property controls which targets the mbed build system allows users to build. You may define targets as parents for other targets. When you define such a target, its description must set the `public` property to `false`. `Target`, shown above, sets `public` to `false` for this reason.
 
 If `public` is not defined for a target, it defaults to `true`.
 
 <span class="notes">**Note:** Unlike other target properties, **the value of `public` is not inherited from a parent to its children**.</span>
 
-## `macros`, `macros_add` and `macros_remove`
+### `macros`, `macros_add` and `macros_remove`
 
 The `macros` property defines a list of macros that are available when compiling code. You may define these macros with or without a value. For example, the declaration `"macros": ["NO_VALUE", "VALUE=10"]` will add `-DNO_VALUE -DVALUE=10` to the compiler's command-line.
 
@@ -110,33 +110,33 @@ For example:
 
 In this configuration, the value of `TargetB.macros` is `["PARENT_MACRO1", "CHILD_MACRO1"]`.
 
-## `extra_labels`, `extra_labels_add` and `extra_labels_remove`
+### `extra_labels`, `extra_labels_add` and `extra_labels_remove`
 
 The list of _labels_ defines how the build system looks for sources, include directories and so on. `extra_labels` makes the build system aware of additional directories that it must scan for such files.
 
 When you use target inheritance, you may alter the values of `extra_labels` using `extra_labels_add` and `extra_labels_remove`. This is similar to the `macros_add` and `macros_remove` mechanism described in the previous section.
 
-## `features`, `features_add` and `features_remove`
+### `features`, `features_add` and `features_remove`
 
 The list of _features_ enables software features on a platform. Like `extra_labels`, `features` makes the build system aware of additional directories it must scan for resources.
 
 When you use target inheritance, you may alter the values of `features` using `features_add` and `features_remove`. This is similar to the `macros_add` and `macros_remove` mechanism the previous section describes.
 
-## `device_has`
+### `device_has`
 
 The list in `device_has` defines what hardware a device has.
 
 mbed, libraries and application source code can then select different implementations of drivers based on hardware availability; selectively compile drivers for existing hardware only; or run only the tests that apply to a particular platform. The values in `device_has` are available in C, C++ and assembly language as `DEVICE_` prefixed macros.
 
-## `supported_toolchains`
+### `supported_toolchains`
 
 The `supported_toolchains` property is the list of toolchains that support a target. The allowed values for `supported_toolchains` are `ARM`, `uARM`, `GCC_ARM` and `IAR`.
 
-## `default_toolchain`
+### `default_toolchain`
 
 The `default_toolchain` property names the toolchain that compiles code for this target in the Online Compiler. Possible values for `default_toolchain` are `ARM` or `uARM`.
 
-## `post_binary_hook`
+### `post_binary_hook`
 
 Some targets require specific actions to generate a programmable binary image. Specify these actions using the `post_binary_hook` property and custom Python code. The value of `post_binary_hook` must be a JSON object with keys `function` and optionally `toolchain`. Within the `post_binary_hook` JSON object, the `function` key must contain a Python function that is accessible from the namespace of `tools/targets/__init__.py`, and the optional `toolchain` key must contain a list of toolchains that require processing from the `post_binary_hook`. When you do not specify the `toolchains` key for a `post_binary_hook`, you can assume the `post_binary_hook` applies to all toolcahins. For the `TEENSY3_1` target above, the definition of `post_binary_hook` looks like this:
 
@@ -167,28 +167,28 @@ class TEENSY3_1Code:
 
 The `post_build_hook` for the `TEENSY3_1` converts the output file (`binf`) from binary format to Intel HEX format. See the other hooks in `tools/targets/__init__.py` for more examples of hook code. 
 
-## `device_name`
+### `device_name`
 
 Use this property to pass necessary data for exporting to various third party tools and IDEs and for building applications with bootloaders.
 
 Please see [exporters.md](exporters.md) for information about this field.
 
-## `OUTPUT_EXT`
+### `OUTPUT_EXT`
 
 The `OUTPUT_EXT` property controls the file type emitted for a target by the build system. You may set `OUTPUT_EXT` to `bin` for binary format, `hex` for Intel HEX format and `elf` for ELF format. We discourage using the `elf` value for `OUTPUT_EXT` because the build system must always emit an ELF file. 
 
-## `default_lib`
+### `default_lib`
 
 The `delault_lib` property controls which library, small or standard, the `GCC_ARM` toolchain links. The `default_lib` property may take on the values `std` for the standard library and `small` for the reduced size library.
 
-## `bootloader_supported`
+### `bootloader_supported`
 
 The `bootloader_supported` property controls whether the build system allows a bootloader or a bootloader-using application to be built for a target. The default value of `bootloader_supported` is `false`.
 
-## `release_versions`
+### `release_versions`
 
 The `release_versions` property is a list of major versions of mbed OS that the target supports. The list within `release_versions` may only contain `2`, indicating that the support of mbed OS 2, and `5`, indicating the support of mbed OS 5. We build all targets that are released for mbed OS 2 as a static library. Targets are released for mbed OS 2 by putting a `2` in the `release_version` list.
 
-## `supported_form_factors`
+### `supported_form_factors`
 
 The `supported_form_factors` property is an optional list of form factors that a development board supports. You can use this property in C, C++ and assembly language by passing a macro prefixed with `TARGET_FF_` to the compiler. The accepted values for `supported_form_factors` are `ARDUINO`, which indicates compatibility with Arduino headers, and `MORPHO`, which indicates compatibility with ST Morpho headers.