docs: Update proposal process (#91)

### Motivation

The proposal process documentation currently suggests including the
implementation along with the proposal. Proposals make sense for
features that require up-front design or have complex or controversial
API implications. Changes that do not require up-front design are better
served with a pull-request for the change (and potentially additional
non-proposal documentation).

### Modifications

Adjust the wording of the proposal process to indicate that prototypes
should be on a separate branch for reference.

### Result

Proposals are made independently of the change.

### Test Plan

n/a.

Sources/swift-openapi-generator/Documentation.docc/Proposals/Proposals.md

@@ -8,7 +8,7 @@ For non-trivial changes that affect the public API, the Swift OpenAPI Generator
 
 Writing a proposal first helps discuss multiple possible solutions early, apply useful feedback from other contributors, and avoid reimplementing the same feature multiple times.
 
-While it's encouraged to get feedback by opening a pull request with a proposal early in the process, it's also important to consider the complexity of the implementation when evaluating different solutions (as per <doc:Project-scope-and-goals>). For example, this might mean including a prototype implementation of the feature in the same PR as the proposal document.
+While it's encouraged to get feedback by opening a pull request with a proposal early in the process, it's also important to consider the complexity of the implementation when evaluating different solutions (as per <doc:Project-scope-and-goals>). For example, this might mean including a link to a branch containing a prototype implementation of the feature in the pull request description.
 
 > Note: The goal of this process is to help solicit feedback from the whole community around the project, and we will continue to refine the proposal process itself. Use your best judgement, and don't hesitate to propose changes to the proposal structure itself!