feat: moving content out of appendix. (#1057)

As discussed in #1048, the appendix today is not used
as a location to discuss in-depth design decisions as
is stated in AIP-8, but is instead used to state content
that should be in the general AIP guidance.

Correcting those examples.

Author: toumorokoshi

aip/aog/3021.md

@@ -35,7 +35,7 @@ enough to be modeled in a permanent/unversioned way, then API author **should**
 consider proposing a new Actions on Google common type in
 [google.actions.type.\*][actions-type].
 
-The guidance in the appendix of [AIP-213][] also applies to creating new
+The guidance in [AIP-213][] also applies to creating new
 Actions on Google common types. Specifically, API authors proposing new types
 **should** consider whether a new type should be a Google-wide common type
 rather than an Actions on Google common type. One exception to this is that new

aip/general/0162.md

@@ -389,7 +389,7 @@ message DeleteBookRevisionRequest {
   - The response **should** include the fully-populated resource unless it is
     infeasible to do so.
 
-## Appendix: Character Collision
+### Character Collision
 
 Most resource names have a restrictive set of characters, but some are very
 open. For example, Google Cloud Storage allows the `@` character in filenames,

aip/general/0194.md

@@ -38,8 +38,6 @@ error codes:
   generally transient. It is retryable under the expectation that the
   connection will become available (soon).
 
-## Appendix
-
 ### Non-retryable codes
 
 The following codes **should not** be automatically retried for any request:

aip/general/0213.md

@@ -120,7 +120,7 @@ and the definitive list is always [the code][type], several types deserve note:
 [time_of_day]: https://github.com/googleapis/googleapis/blob/master/google/type/timeofday.proto
 <!-- prettier-ignore-end -->
 
-## Appendix: Adding to common protos
+### Adding to common protos
 
 Occasionally, it may be useful to add protos to these packages or to add to the
 list of commonly-available protos. In order to do this, [open an issue][] on

aip/general/0216.md

@@ -51,9 +51,6 @@ large number of states simply because they exist in your internal system is
 unnecessary and adds confusion for customers. Each state must come with a use
 case for why it is necessary.
 
-A list of commonly used enum values for states is in the appendix of this
-document.
-
 ### Output only
 
 The field referencing the `State` enum in a resource **should** behave and be
@@ -189,13 +186,13 @@ above. In this situation, the API may be better off exposing a
 `google.protobuf.Timestamp delete_time`, and instructing users to rely on
 whether it is set to determine deletion.
 
-## Appendix: Common states
+### Common states
 
 The following is a list of states in common use. APIs **should** consider prior
 art when determining state names, and **should** value local consistency above
 global consistency in the case of conflicting precedent.
 
-### Resting states
+#### Resting states
 
 "Resting states" are lifecycle states that, absent user action, are expected to
 remain indefinitely. However, the user can initiate an action to move a
@@ -210,7 +207,7 @@ resource in a resting state into certain other states (resting or active).
 - `SUSPENDED`
 - `VERIFIED`
 
-### Active states
+#### Active states
 
 "Active states" are lifecycle states that typically resolve on their own into a
 single expected resting state.