DOCS: Define the request line Evidence keys for signature verification

[jwrosewell]

The problem

A Web Bot Auth signature names the parts of the request it covers, and
the strongest coverage an agent can choose takes in the request line,
being the method, the path and the query string. Verification rebuilds
each covered part byte for byte, so a verifier that cannot rebuild the
request line can only answer "could not check" for exactly the
best behaved agents. The specification defined no Evidence keys for
the request line, so no implementation had a contract to build
against. This is a specification concern, not a .NET one, because
every language's web integration must supply the same keys under the
same names.

What was changed

Three pages on pipeline-specification:

1. features/web-integration.md, the Populating Evidence list gains
   three keys, server.request-method, server.request-path and
   server.request-query, with a paragraph requiring the values byte
   for byte as sent with no decoding, requiring all three on every
   request (the query key empty when the request has no query string,
   so an absent key always means the integration does not supply the
   request line), and noting the accepted-Evidence feature means a
   Pipeline without an element asking for the keys carries no new
   values.
2. features/evidence.md, the defined key examples gain the same
   three, with a pointer to the web integration page for the detail.
3. pipeline-elements/agent-signature-element.md, the derived
   component rules now say how @method, @path, @query and
   @target-uri are built from the three keys, including the RFC 9421
   section 2.2.7 leading ? rule, in place of the previous statement
   that the request line is not in Evidence.

The server prefix is the specification's existing category for
request values that fit no other prefix, the same family as
server.client-ip. The whole query string is carried separately from
the decoded query.[parameter name] pairs because the decoded pairs
lose ordering and encoding and cannot rebuild the original.

What follows

51Degrees/pipeline-dotnet#374 implements the keys in the .NET web
integrations, and the other language ports follow the same contract
from this page.