Clarify whether ACP process is optional

Note that an ACP is not strictly required: you can just go ahead and submit a pull request with an implementation of your proposed API, with the risk of wasted effort if the library team ends up rejecting this feature. However do note that this risk is always present even if an ACP is accepted, as the library team can end up rejecting a feature in the later parts of the stabilization process.
https://github.com/rust-lang/std-dev-guide/blob/23d4ff6e2372489b0a9fe42b69a85611e40a9693/src/development/feature-lifecycle.md?plain=1#L26

When contributing to std, a lot of contributors find this line and believe they don't have to file an ACP. They may submit a PR, wait days for a review, and finally get a response that the PR can't be reviewed until an ACP has been accepted.

Filing an ACP seems de facto required and would cut out a lot of wasted lead time on contributors' behalf if they submitted the ACP along with the PR instead of risking its optionality. Being told you need to write a report days or weeks after you filed the PR, while it's no longer fresh in your mind, is a demotivating and frustrating experience for contributors.

Observing new feature addition PRs since the ACP process was added, it seems overwhelmingly that these PRs require an ACP. I would like to see this clause clarified to encourage contributors to submit an ACP anyway to make the process smoother and less surprising for them.

As a sidenote, I needed to file an ACP for extending a pre-existing feature to another type, so perhaps that should be called out too. I don't know the policy, but for example: "Expanding the scope of an already existing feature may/will require an ACP." This way contributors won't be surprised and will be prepared to do that if the necessary.

Read src/development/feature-lifecycle.md around the linked line and the surrounding ACP guidance first. Clarify when contributors should file an ACP, including changes that extend an existing feature, so the guide matches the team's policy and avoids surprising contributors.