Add basic ADR doc setup and first LVM ADR

This commit introduces Architectural Decision Records. To quote:

> Architectural Decision Records (ADRs)
>
> An Architectural Decision (AD) is a software design choice that
> addresses a functional or non-functional requirement that is
> architecturally significant. An Architecturally Significant
> Requirement (ASR) is a requirement that has a measurable effect on a
> software system’s architecture and quality. An Architectural Decision
> Record (ADR) captures a single AD, such as often done when writing
> personal notes or meeting minutes; the collection of ADRs created
> and maintained in a project constitute its decision log. All these
> are within the topic of Architectural Knowledge Management (AKM), but
> ADR usage can be extended to design and other decisions (“any
> decision record”).

Taken from https://adr.github.io/

This commit also adds the first ADR; both as an example as well as a
serious proposal. This ADR is a product of discussions around
encrypted swap, hibernation, onboarding of new devices, and fragmentation.

doc/adr/01-lvm.md

@@ -0,0 +1,13 @@
+# PubSolarOS ADR 01: LVM on luks as default for drive management
+
+In the context of drive mounting and disk partitioning,
+
+facing a fragmented ecosystem,
+
+we decided for LVM on luks with encrypted swap as the assumed default installation type,
+
+and neglected luks on LVM, unencrypted installs, or non-LVM install methods,
+
+to achieve a streamlined and opiniated nix config, an increased flexibility in partitioning, and more secure defaults,.
+
+accepting a more laborious setup.

doc/adr/README.md

@@ -0,0 +1,3 @@
+# Architectural Decision Records
+
+**For an explanation of ADR, see https://adr.github.io/**

doc/adr/TEMPLATE.md

@@ -0,0 +1,27 @@
+# Long form
+
+In the context of <use case/user story u>,
+
+facing <concern c>
+
+we decided for <option o>
+
+and neglected <other options>,
+
+to achieve <system qualities/desired consequences>,
+
+accepting <downside d/undesired consequences>,
+
+because <additional rationale>.
+
+# Short form
+
+In the context of <use case/user story u>,
+
+facing <concern c>
+
+we decided for <option o>
+
+to achieve <quality q>,
+
+accepting <downside d>.