Adds initial goals doc (#7)

* Adds initial goals doc

Signed-off-by: alex <alex@datawire.io>

* Populates content from the google docs, comments and discussions into the markdown file

Signed-off-by: alex <alex@datawire.io>

* Update GOALS.md

Co-authored-by: Arko Dasgupta <arkodg@users.noreply.github.com>
Signed-off-by: alex <alex@datawire.io>

* Splits the goals into "Expressive API" and "Simplified deployment"

Signed-off-by: alex <alex@datawire.io>

* Revised personas, direct xDS references and misc wording

Signed-off-by: alex <alex@datawire.io>

* GOALS: "the Envoy Gateway" → "Envoy Gateway"

Signed-off-by: Luke Shumaker <lukeshu@datawire.io>

* GOALS: "the Envoy Proxy" → "Envoy Proxy"

Signed-off-by: Luke Shumaker <lukeshu@datawire.io>

* GOALS: Fuss with wording for readability

Signed-off-by: Luke Shumaker <lukeshu@datawire.io>

* GOALS: Simplify the app-dev persona

This is the description suggested by Daneyon on GH, but with the phrase
", e.g. path-based routing" removed per Alex and Nick.

Co-authored-by: danehans <daneyonhansen@gmail.com>
Signed-off-by: Luke Shumaker <lukeshu@datawire.io>

* GOALS: Try to better highlight that it's Gateway API

Signed-off-by: Luke Shumaker <lukeshu@datawire.io>

* GOALS: Use just "the API" rather than "the [adjective] API" for readability

Signed-off-by: Luke Shumaker <lukeshu@datawire.io>

* GOALS: Mention vendor-extensibility in the intro paragraph

Signed-off-by: Luke Shumaker <lukeshu@datawire.io>

* GOALS: Have a go at "batteries included"

Signed-off-by: Luke Shumaker <lukeshu@datawire.io>

* GOALS: Fix a sentence with mixed tense

Co-authored-by: Arko Dasgupta <arkodg@users.noreply.github.com>

Co-authored-by: Arko Dasgupta <arkodg@users.noreply.github.com>
Co-authored-by: Luke Shumaker <lukeshu@datawire.io>
Co-authored-by: danehans <daneyonhansen@gmail.com>
Co-authored-by: Luke Shumaker <lukeshu@lukeshu.com>

GOALS.md

@@ -0,0 +1,79 @@
+# Goals
+
+The high-level goal of the Envoy Gateway project is to attract more users to Envoy by lowering barriers to adoption 
+through expressive, extensible, role-oriented APIs that support a multitude of ingress and L7/L4 traffic routing
+use cases; and provide a common foundation for vendors to build value-added products without having to re-engineer
+fundamental interactions.
+
+## Objectives
+
+### Expressive API
+The Envoy Gateway project will expose a simple and expressive API, with defaults set for many capabilities.
+
+The API will be the Kubernetes-native [Gateway API][], plus Envoy-specific extensions and extension points.  This
+expressive and familiar API will make Envoy accessible to more users, especially application developers, and make Envoy
+a stronger option for "getting started" as compared to other proxies.  Application developers will use the API out of
+the box without needing to understand in-depth concepts of Envoy Proxy or use OSS wrappers.  The API will use familiar
+nouns that [users](#personas) understand.
+
+The core full-featured Envoy APIs will remain available for those who need more capability and for those who 
+add functionality on top of Envoy, such as commercial API gateway products.
+
+This expressive API will not be implemented by Envoy Proxy, but rather an officially supported translation layer 
+on top.
+
+### Batteries included
+Envoy Gateway will simplify how Envoy is deployed and managed, allowing application developers to focus on 
+delivering core business value.
+
+The project plans to include additional infrastructure components required by users to fulfill their Ingress and API
+gateway needs: It will handle Envoy infrastructure provisioning (e.g. Kubernetes Service, Deployment, et cetera), and
+possibly infrastructure provisioning of related sidecar services.  It will include sensible defaults with the ability to
+override.  It will include channels for improving ops by exposing status through API conditions and Kubernetes status
+sub-resources.
+
+Making an application accessible needs to be a trivial task for any developer. Similarly, infrastructure administrators
+will enjoy a simplified management model that doesn't require extensive knowledge of the solution's architecture to
+operate.
+
+### All environments
+Envoy Gateway will support running natively in Kubernetes environments as well as non-Kubernetes deployments.
+
+Initially, Kubernetes will receive the most focus, with the aim of having Envoy Gateway become the de facto 
+standard for Kubernetes ingress supporting the [Gateway API][].
+Additional goals include multi-cluster support and various runtime environments.
+
+### Extensibility
+Vendors will have the ability to provide value-added products built on the Envoy Gateway foundation.
+
+It will remain easy for end-users to leverage common Envoy Proxy extension points such as providing an implementation
+for authentication methods and rate-limiting.  For advanced use cases, users will have the ability to use the full power
+of xDS.
+
+Since a general-purpose API cannot address all use cases, Envoy Gateway will provide additional extension points 
+for flexibility. As such, Envoy Gateway will form the base of vendor-provided managed control plane solutions, 
+allowing vendors to shift to a higher management plane layer.
+
+## Non-objectives
+
+### Cannibalize vendor models
+Vendors need to have the ability to drive commercial value, so the goal is not to cannibalize any existing vendor 
+monetization model, though some vendors may be affected by it.
+
+### Disrupt current Envoy usage patterns
+Envoy Gateway is purely an additive convenience layer and is not meant to disrupt any usage pattern of any user 
+with Envoy Proxy, xDS, or go-control-plane.
+
+## Personas
+_In order of priority_
+
+### 1. Application developer
+The application developer spends the majority of their time developing business logic code.  They require the ability to
+manage access to their application.
+
+### 2. Infrastructure administrators
+The infrastructure administrators are responsible for the installation, maintenance, and operation of
+API gateways appliances in infrastructure, such as CRDs, roles, service accounts, certificates, etc.
+Infrastructure administrators support the needs of application developers by managing instances of Envoy Gateway.
+
+[Gateway API]: https://gateway-api.sigs.k8s.io/