Fix headings in 2 developer docs pages

Use heading levels consistently, especially:
 - do not use title in the middle of the page - there is just one page
   title, at the top, added automatically
 - do not skip levels (if there is ###, put ## before)

developer/building/development-workflow.md

@@ -15,7 +15,7 @@ A workflow for developing Qubes OS+
 First things first, setup [QubesBuilder](/doc/qubes-builder/). This guide
 assumes you're using qubes-builder to build Qubes.
 
-# Repositories and committing Code
+## Repositories and committing Code
 
 Qubes is split into a bunch of git repos. These are all contained in the
 `qubes-src` directory under qubes-builder. Subdirectories there are separate

developer/system/template-implementation.md

@@ -10,6 +10,8 @@ ref: 58
 title: Template implementation
 ---
 
+## Block devices of a VM
+
 Every VM has 4 block devices connected:
 
 - **xvda** – base root device (/) – details described below
@@ -17,7 +19,7 @@ Every VM has 4 block devices connected:
 - **xvdc** – volatile.img, discarded at each VM restart – here is placed swap and temporal "/" modifications (see below)
 - **xvdd** – modules.img – kernel modules and firmware
 
-## private.img (xvdb)
+### private.img (xvdb)
 
 This is mounted as /rw and here is placed all VM private data. This includes:
 
@@ -27,7 +29,7 @@ This is mounted as /rw and here is placed all VM private data. This includes:
 
 **Note:** Whenever a TemplateBasedVM is created, the contents of the `/home` directory of its parent TemplateVM [are *not* copied to the child TemplateBasedVM's `/home`](/doc/templates/#inheritance-and-persistence). The child TemplateBasedVM's `/home` is independent from its parent TemplateVM's `/home`, which means that any changes to the parent TemplateVM's `/home` will not affect the child TemplateBasedVM's `/home`. Once a TemplateBasedVM has been created, any changes in its `/home`, `/usr/local`, or `/rw/config` directories will be persistent across reboots, which means that any files stored there will still be available after restarting the TemplateBasedVM. No changes in any other directories in TemplateBasedVMs persist in this manner. If you would like to make changes in other directories which *do* persist in this manner, you must make those changes in the parent TemplateVM.
 
-## modules.img (xvdd)
+### modules.img (xvdd)
 
 As the kernel is chosen in dom0, there must be some way to provide matching kernel modules to VM. Qubes kernel directory consists of 3 files:
 
@@ -39,7 +41,7 @@ Normally kernel "package" is common for many VMs (can be set using qvm-prefs). O
 
 There is a special case when the VM can have a custom kernel – when it is updateable (StandaloneVM or TemplateVM) and the kernel is set to "none" (by qvm-prefs). In this case the VM uses the kernel from the "kernels" VM subdir and modules.img is attached as R/W device.
 
-# Qubes TemplateVM implementation
+## Qubes TemplateVM implementation
 
 TemplateVM has a shared root.img across all AppVMs that are based on it. This mechanism has some advantages over a simple common device connected to multiple VMs:
 
@@ -50,7 +52,7 @@ There are two layers of the device-mapper snapshot device; the first one enables
 
 ![TemplateSharing2.png](/attachment/doc/TemplateSharing2.png)
 
-## Snapshot device in Dom0
+### Snapshot device in Dom0
 
 This device consists of:
 
@@ -61,7 +63,7 @@ The above is achieved through creating device-mapper snapshots for each version
 
 When an AppVM is stopped the xen hotplug script checks whether the device is still in use – if it is not, the script removes the snapshot and frees the loop device.
 
-### Changes to template filesystem
+#### Changes to template filesystem
 
 In order for the full potential of the snapshot device to be realized, every change in root.img must save the original version of the modified block in root-cow.img. This is achieved by a snapshot-origin device.
 
@@ -69,7 +71,7 @@ When TemplateVM is started, it receives the snapshot-origin device connected as
 
 When TemplateVM is stopped, the xen script moves root-cow.img to root-cow.img.old and creates a new one (using the `qvm-template-commit` tool). The snapshot device will remain untouched due to the loop device, which uses an actual file on the disk (by inode, not by name). Linux kernel frees the old root-cow.img files as soon as they are unused by all snapshot devices (to be exact, loop devices). The new root-cow.img file will get a new inode number, and so new AppVMs will get new snapshot devices (with different names).
 
-### Rollback template changes
+#### Rollback template changes
 
 There is possibility to rollback last template changes. Saved root-cow.img.old contains all changes made during last TemplateVM run. Rolling back changes is done by reverting this "binary patch".
 
@@ -85,7 +87,7 @@ Steps performed by **qvm-revert-template-changes**:
 6. Cleanup snapshot device (if nobody uses it at the moment).
 7. Move *root-cow.img.old* to *root-cow.img* (overriding existing file).
 
-## Snapshot device in AppVM
+### Snapshot device in AppVM
 
 Root device is exposed to AppVM in read-only mode. AppVM can write only in:
 
@@ -99,7 +101,7 @@ volatile.img is divided into two partitions:
 
 Inside of an AppVM, the root device is wrapped by the snapshot in the first partition of volatile.img. Therefore, the AppVM can write anything to its filesystem – however, such changes will be discarded after a restart.
 
-## StandaloneVM
+### StandaloneVM
 
 Standalone VM enables user to modify root filesystem persistently. It can be created using *--standalone* switch to *qvm-create*.