Add readme and template for ADRs (#445)

* Add readme and template for ADRs

* Update readme for adr-tools

* Update template to match adr-tools

* Move files to doc from docs per adr-tools

doc/adr/README.md

@@ -0,0 +1,7 @@
+## ADR == Architecture Decision Records
+
+During meetings, it isn't unusual to make decisions that impact a product's architecture or operation.  While these decisions are frequently captured in the meeting minutes, it is time-consuming and inefficient to wade through meeting minutes looking for those decisions.  Therefore, we will capture them using [adr-tools](https://github.com/npryce/adr-tools) as it handles numbering, file naming, and filling in the ADR title.  Additionally, it provides tooling for actions like superseding ADRs with newer decisions.  If you prefer, you can use the [ADR template](./adr-template.md) but make sure you follow the numbering and file naming similarly as adr-tools.
+
+The ADR is a lightweight process for documenting these decisions. By storing them in the repository with the code, we will have a record and history.
+
+The concept of ADRs originated in [Documenting architecture decisions - Michael Nygard](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions).  

doc/adr/adr-template.md

@@ -0,0 +1,19 @@
+
+# 0. TEMPLATE
+[The number of the ADR followed by a Short Description. E.g., 1. Record architecture decisions.  The file name should match the title, e.g., 0001-record-architecture-decisions]
+
+## Status
+
+[What is the status - Proposed, Accepted, Rejected, Deprecated, Superseded, etc.? If superseded, add the ADR that replaced it or information in the context for why.]
+
+## Context
+
+[The issue motivating this decision, and any context that influences or constrains the decision. ]
+
+## Decision
+
+[The change that we're proposing or have agreed to implement.]
+
+## Consequences
+
+[What becomes easier or more difficult to do and any risks introduced by the change that will need to be mitigated.]