Allow all guards to access &Request

[the10thWiz]

There are a number of situations where it would be convenient to wrap parsing and external validation into a single implementation.

Example: #2902

A user is looking to do CSRF token validation. Parsing a CSRF token is trivial, but it would be nice if the FromFormField (or other guard) could access managed state to validate that the CSRF token is actually valid.

Example: https://matrix.to/#/!kDIcCXWSVfdahNCJWq:mozilla.org/$H49UrdMJU99dpzGxB_0oXyd0SY-IswQIM6WXMIv2ZH8?via=mozilla.org&via=matrix.org&via=catgirl.cloud

A user is looking to augment an OrgId with details about the organization. In this specific case, the OrdId is a uuid, and the user want to know 'does this id exist in the database?', and 'does this id have an active subscription?'.

Implementation

Trivially, FromParam, FromSegements, FromForm, etc would simply have a &Request parameter added.

We could also consider changing the semantics of #[route], to parse path and query parameters before request guards. This would allow these parameters to place values in the local_cache, for later request guards to validate against. I'm not convinced this is a useful change overall, since the vast majority of cases should be handled by simply doing all validation in the path/query guard itself.

Counterarguments

(I believe) The primary reason we have not exposed the &Request to these types of guards before is quite simple - we want a clear separation of duties. In 0.5, a path/query guard only parses a value, and does no validation. However, it's often quite useful to group these together - and it makes is quite easy to form a useful type system.

Example 1, rehashed

Using 0.5, the id parameter would likely just be Uuid - since that's all you can validate anyway. Then, each route would need to call a method to convert a Uuid to an OrgId, which represents a valid organization, and can be used safely in all future database calls.

With this change, the id parameter would be OrgId. It would call Uuid's parse method to extract it, and make the needed calls to ensure the id is a valid OrgId. This also allows the API to be extremely expressive for both the API writer, and any API consumer. In 0.5, the expressiveness can be retained for the API consumer, but at the cost of additional boilerplate code to handle a UnvalidatedOrgId vs ValidatedOrgId type difference.