Update headings in bootloader.md

Remove code formatting for improved UX.

Author: Amanda Butler

docs/reference/configuration/bootloader.md

@@ -16,39 +16,39 @@ All of these parameters are valid in `targets.json`, `mbed_lib.json` and `mbed_a
 
 The presence of any of these parameters defines `APPLICATION_ADDR` and `APPLICATION_SIZE` for C and C++ and `MBED_APP_START` and `MBED_APP_SIZE` for the linker.
 
-### `target.mbed_app_start`
+### target.mbed_app_start
 
 This parameter defines the start address of your application. You are responsible for the alignment of this address with respect to the flash layout and vector table size of the MCU you are using. When not used in conjunction with `target.mbed_app_size`, the application being built uses the remainder of ROM.
 
 The value of this parameter is available to C and C++ as `APPLICATION_ADDR` and to the linker as `MBED_APP_START`.
 
 This configuration parameter conflicts with `target.bootloader_img` and `target.restrict_size`.
 
-### `target.mbed_app_size`
+### target.mbed_app_size
 
 This parameter defines the size of your application. You may use `target.mbed_app_start` in conjunction with this parameter to set the start address, as well as the size. When `target.mbed_app_start` is not present, the application starts at the beginning of ROM. You are responsible for the alignment of the end address of the application with respect to the flash layout and vector table size of the MCU you are using.
 
 The value of this parameter is available to C and C++ as `APPLICATION_SIZE` and to the linker as `MBED_APP_SIZE`.
 
 This parameter conflicts with `target.bootloader_img` and `target.restrict_size`.
 
-### `target.bootloader_img`
+### target.bootloader_img
 
 This parameter defines the bootloader image to be used during the built-in postbuild merge process. `target.bootloader_img` implicitly defines the start of the current application's code segment by taking the size of the bootloader and rounding up to the next flash erase block boundary. The built-in postbuild merge process automatically combines the current application with the image this parameter references.
 
 The start address of the current application, as computed above, is available to C and C++ as `APPLICATION_ADDR` and to the linker as `MBED_APP_START`. The size of the current application is available as `APPLICATION_SIZE` and `MBED_APP_SIZE`. This parameter also defines `BOOTLOADER_ADDR` and `BOOTLOADER_SIZE` as the start address and size of the provided bootloader.
 
 You may use this parameter in conjunction with `target.restrict_size`, `target.header_format`, `target.header_offset` and `target.app_offset`. It conflicts with `target.mbed_app_start` and `target.mbed_app_size`. When you use it with `target.restrict_size`, that parameter defines the size of the application. Otherwise, the size is the remainder of ROM.
 
-### `target.restrict_size`
+### target.restrict_size
 
 This parameter restricts the size of the application to be at most the specified size rounded down to the nearest integer multiple of flash erase blocks. When `target.bootloader_img` is present, the start of the current application's code segment is computed as above; otherwise, the start address is the beginning of ROM. The postbuild merge process pads the resulting bootloader binary to its end address.
 
 The start address of the current application, as computed above, is available to C and C++ as `APPLICATION_ADDR` and to the linker as `MBED_APP_START`. The size of the current application is available as `APPLICATION_SIZE` and `MBED_APP_SIZE`. This parameter also defines `POST_APPLICATION_ADDR` and `POST_APPLICATION_SIZE` as the start address and size of the region after the application.
 
 You may use this parameter in conjunction with `target.bootloader_img`, `target.header_format`, `target.header_offset` and `target.app_offset`. It conflicts with `target.mbed_app_start` and `target.mbed_app_size`. When used with `target.bootloader_img`, that parameter defines the start of the application. Otherwise, the start is the start of ROM.
 
-### `target.header_format`
+### target.header_format
 
 The `target.header_format` configuration key defines an application header as a list of tuples. Each tuple represents a single element of the header format as a name (a valid C identifier), a type, a subtype and finally a single argument. For example, the const type defines subtypes for common sizes of constants, including the 32be subtype that indicates the constant is represented as 32-bit big endian. The following is a list of all types and subtypes that the Mbed OS build tools support.
 
@@ -82,13 +82,13 @@ The Mbed OS tools build items in the application header starting where the previ
 
 You may use this parameter in conjunction with `target.bootloader_img`, `target.restrict_size`, `target.header_offset` and `target.app_offset`. It conflicts with `target.mbed_app_start` and `target.mbed_app_size`. When used with `target.bootloader_img`, that parameter defines the start of the application. Otherwise, the start is the start of ROM.
 
-### `target.header_offset`
+### target.header_offset
 
 This parameter directly assigns the offset of the beginning of the header section defined in `target.header_format`. This parameter creates space between the bootloader and application header or asserts that the bootloader is at most as big as the specified offset.
 
 You may use this parameter in conjunction with `target.bootloader_img`, `target.restrict_size`, `target.header_format` and `target.app_offset`. It conflicts with `target.mbed_app_start` and `target.mbed_app_size`.
 
-### `target.app_offset`
+### target.app_offset
 
 This parameter assigns the offset of the beginning of the application section that follows the header. This parameter creates space between the application header and the application.