Add a style guide to the website README.md

Add some pointers for the style that we expect in Markdown submitted for the
Apertis website. These are things that get picked up in review, stating them
upfront may reduce the time needed to review submissions.

Signed-off-by: Martyn Welch <martyn.welch@collabora.com>

README.md

@@ -59,6 +59,55 @@ process will fail when the target page of the reference can not be found,
 causing the CI to fail and thus aids with reducing the risk broken links being
 provided on the website.
 
+## Formatting
+
+Please follow these guidelines to enable us to maintain some consistency across the documentation:
+
+1. **Don't add an "Introduction" heading as the first line in the document**:
+   It is generally understood that the first block of text in a document will
+   introduce what follows, the title is redundant.
+
+2. **Titles should be in
+   [Title Case](https://en.wikipedia.org/wiki/Title_case)**: This is a widely
+   used convention.
+
+3. **Use the
+   [primary Markdown format for titles](https://www.markdownguide.org/basic-syntax/#headings)**:
+   The expected title format is appending one or more `=` to the beginning of
+   the line holding the title.  This format has greater flexibility than the
+   alternative form.
+
+4. **Use
+   [indented code blocks](https://www.markdownguide.org/basic-syntax/#code-blocks)
+   for command line examples**: These should be indented with 4 spaces (beyond
+   any existing indentation, such as for lists).
+
+5. **Use
+   [Fenced Code Blocks](https://www.markdownguide.org/extended-syntax/#fenced-code-blocks)
+   for file contents**: These should be marked with a syntax highlighting hint
+   where appropriate and typically the `numberLines` hint to cause the blocks
+   to be rendered with line numbers. For example, for C source code:
+
+       ``` c numberLines
+       #include <stdio.h>
+
+       int main(int argc, char argv*)
+       {
+           print("Hello World\n");
+           return 0;
+       }
+       ```
+
+6. **Try and keep to 80 character width lines**: This makes it easier for some
+   to read. It is questionable whether this helps with viewing changes, as
+   rewrapping can make changes unclear, but gitlab currently doesn't do a
+   great job of rendering changes to long lines, so this is the style that's
+   been chosen.
+
+   **Note**: Please keep Markdown URLs on a single line, even if this stretches
+   the line beyond 80 characters as it helps with parsing/scripting URL checks
+   etc.
+
 ## Generating PDFs
 
 In order to generate PDFs, we are getting Hugo to create a simplified HTML