Update client information discovery method

The current method of client information discovery (fetching the client_id and parsing the HTML page for microformats) has received a lot of pushback from various people otherwise interested in implementing IndieAuth. This method is also somewhat limited in that it requires defining a Microformats vocabulary for client information, rather than using the existing vocabulary of client information that's defined by [RFC 7591 Dynamic Client Registration](https://datatracker.ietf.org/doc/html/rfc7591).

An alternative proposal for client information discovery was proposed in [draft-looker-oauth-client-id-scheme](https://www.ietf.org/archive/id/draft-looker-oauth-client-id-scheme-00.html), where the AS uses the client ID URL as the base URL and appends a `.well-known` string in order to find a JSON document with the client metadata. While this approach gets around the HTML/Microformats challenges, it is also not ideal because of the requirement of the `.well-known` path.

A middle ground (and interestingly, [what Solid-OIDC has done](https://solidproject.org/TR/oidc#clientids-document)), is to instead make the client ID URL _be_ the URL to the metadata document.

So an IndieAuth client such as https://webmention.io would choose a URL to host its client metadata document, for example `https://webmention.io/indieauth/client.json`. This is the value it would use as the `client_id` in the OAuth flow.

The AS would see the `client_id` URL in the authorize request and fetch the URL directly in order to find the client metadata. The metadata values would be the values defined by [Dynamic Client Registration](https://datatracker.ietf.org/doc/html/rfc7591#section-2), such as `redirect_urls`, `client_name`, etc.

Start by reviewing the existing client information discovery implementation described in the issue, then read RFC 7591 and the linked draft and Solid-OIDC example. Compare the current HTML and Microformats approach with using the client_id URL as the metadata document URL. Done means the selected discovery behavior and supported metadata fields are defined consistently with the chosen proposal.

Written by the indexing model from the issue text.