*: Use four-space indents for list-entry continuation

The Markdown spec is liberal for the first paragraph [1]:

> To make lists look nice, you can wrap items with hanging
> indents... But if you want to be lazy, you don’t have to...

However, it's a bit more strict about subsequent paragraphs [1]:

> List items may consist of multiple paragraphs. Each subsequent
> paragraph in a list item must be indented by either 4 spaces or one
> tab:

That doesn't matter for our use here, because all of our entries are
single-paragraph.  But runtime-spec has been bitten by Pandoc
strictness for multiple paragraphs before [2], and their RELEASES.md
has used four-space indents since [3].  By adopting the stricter
behavior here, we make it easier for OCI Projects to stay synchronized
with the template while maintaining their stricter local conventions.
OCI Projects that do not have strict local conventions probably don't
care either way.

[1]: https://daringfireball.net/projects/markdown/syntax#list
[2]: opencontainers/runtime-spec#495
[3]: opencontainers/runtime-spec#846

Signed-off-by: W. Trevor King <[email protected]>

Author: wking

MAINTAINERS_GUIDE.md

@@ -25,7 +25,7 @@ It is every maintainer's responsibility to:
 * Expose a clear roadmap for improving their component.
 * Deliver prompt feedback and decisions on pull requests.
 * Be available to anyone with questions, bug reports, criticism etc. on their component.
-  This includes IRC and GitHub issues and pull requests.
+    This includes IRC and GitHub issues and pull requests.
 * Make sure their component respects the philosophy, design and roadmap of the project.
 
 ## How are decisions made?
@@ -44,16 +44,16 @@ a change to the philosophy manifesto. And so on.
 All decisions affecting this project, big and small, follow the same procedure:
 
 1. Discuss a proposal on the [mailing list](CONTRIBUTING.md#mailing-list).
-   Anyone can do this.
+    Anyone can do this.
 2. Open a pull request.
-   Anyone can do this.
+    Anyone can do this.
 3. Discuss the pull request.
-   Anyone can do this.
+    Anyone can do this.
 4. Endorse (`LGTM`) or oppose (`Rejected`) the pull request.
-   The relevant maintainers do this (see below [Who decides what?](#who-decides-what)).
-   Changes that affect project management (changing policy, cutting releases, etc.) are [proposed and voted on the mailing list](GOVERNANCE.md).
+    The relevant maintainers do this (see below [Who decides what?](#who-decides-what)).
+    Changes that affect project management (changing policy, cutting releases, etc.) are [proposed and voted on the mailing list](GOVERNANCE.md).
 5. Merge or close the pull request.
-   The relevant maintainers do this.
+    The relevant maintainers do this.
 
 ### I'm a maintainer, should I make pull requests too?
 

RELEASES.md

@@ -43,9 +43,9 @@ Specifications have a variety of different timelines in their lifecycle.
 
 * Pre-v1.0.0 specifications SHOULD release on a monthly cadence to garner feedback.
 * Major specification releases MUST release at least three release candidates spaced a minimum of one week apart.
-  This means a major release like a v1.0.0 or v2.0.0 release will take 1 month at minimum: one week for rc1, one week for rc2, one week for rc3, and one week for the major release itself.
-  Maintainers SHOULD strive to make zero breaking changes during this cycle of release candidates and SHOULD restart the three-candidate count when a breaking change is introduced.
-  For example if a breaking change is introduced in v1.0.0-rc2 then the series would end with v1.0.0-rc4 and v1.0.0.
+    This means a major release like a v1.0.0 or v2.0.0 release will take 1 month at minimum: one week for rc1, one week for rc2, one week for rc3, and one week for the major release itself.
+    Maintainers SHOULD strive to make zero breaking changes during this cycle of release candidates and SHOULD restart the three-candidate count when a breaking change is introduced.
+    For example if a breaking change is introduced in v1.0.0-rc2 then the series would end with v1.0.0-rc4 and v1.0.0.
 * Minor and patch releases SHOULD be made on an as-needed basis.
 
 [charter]: https://www.opencontainers.org/about/governance