design-proposals: Clean template and add feature lifecycle section

As discussed at the unconference for v1.5.0 [1] we should start
documenting the expected lifecycle of a given feature within our design
proposals before later moving this tracking to an issue.

This change cleans up the template, removing multiple top level
headings, adding whitespace around headings and adds a final section
defining the lifecycle of a feature.

[1] https://unconference.kubevirt.io/D62SngbSRXO1uhTAc8Ikqg#xpivarc-Feature-lifecycleFuture-of-proposals---1-1-1-1

Signed-off-by: Lee Yarwood <[email protected]>

design-proposals/proposal-template.md

@@ -1,43 +1,62 @@
+# Proposal Template Title
+
 This template is simply a guide. When making proposals, feel free to add and
 remove portions of this outline to best fit your specific case. There is no
 expectation that people strictly stick to this outline, but it is a good place
-to start. 
+to start.
+
+## Overview
 
-# Overview
 (Provide a brief overview of the topic)
 
 ## Motivation
+
 (Why this enhancement is important)
 
 ## Goals
+
 (The desired outcome)
 
 ## Non Goals
+
 (limitations to the scope of the design)
 
 ## Definition of Users
+
 (who is this feature set intended for)
 
 ## User Stories
+
 (list of user stories this design aims to solve)
 
 ## Repos
+
 (list of repose this design impacts)
 
-# Design
+## Design
+
 (This should be brief and concise. We want just enough to get the point across)
 
 ## API Examples
+
 (tangible API examples used for discussion)
 
 ## Scalability
+
 (overview of how the design scales)
 
 ## Update/Rollback Compatibility
+
 (does this impact update compatibility and how)
 
 ## Functional Testing Approach
+
 (an overview on the approaches used to functional test this design)
 
-# Implementation Phases
+## Implementation Phases
+
 (How/if this design will get broken up into multiple phases)
+
+## Feature lifecycle Phases
+
+(How and when will the feature progress through the Alpha, Beta and GA lifecycle phases)