Bring in the subprotocol (the same as what's used on the desktop client
for public-key authentication) to carry the relevant messages:

- AuthRequest: first step in the flow, the client sends it to signal the
  intent to authenticate to the server.

- AssertCredential and AssertionFinish: server's challenge and client's
  response, respectively, to finalize the flow.

- RegisterCredential and RegistrationFinish: same structure as the
  above. Unlike the simple public-key auth with an out-of-band setup,
  passkeys require user interaction to register. User must be
  authorized.

Validate all relevant checks on the API side, and hand the data over to
the server for it to verify attestations and assertions.

Because it's a primary auth mechanism (not a second factor), require
user verification.

As we don't use any other method on web, add a passkey button as the
only sign-in interface. Passkeys are discoverable, we don't even need a
username.

The hCaptcha integration has been abandoned for a while. It added yet
another questionable third-party API (which also set a Cloudflare
cookie), and its effectiveness is unclear considering its client-side
nature.

A custom CAPTCHA implementation (such as PoW challenge) is an
interesting prospect, but it'll require proper server-side support.

Cookies's use case is to store persistent data and send it to the server
in subsequent requests, such as to remember logged-in sessions. WebAO is
using them to store site settings like ad-hoc hash tables that require
parsing and serialization.

As a nasty side-effect of how cookies work, clients send all their
settings every time they connect to the server. Server has absolutely no
use for them, but each client sends them anyway, which is an
uncalled-for privacy leak.

Remove this mechanism entirely, switch to localStorage which serves
exactly the purpose of per-origin store with data that never leaves the
browser.

Fix relevant breaking changes.

It only caused chat_config.ini to be requested a lot.

These should obey the extension data, but instead they're hardcoded
to predefined PNG and GIF files.

Blips aren't handled correctly every time, resulting in a lot of 404
URLs and invalid blips.

Historically, MC packet ended up in a ridiculous spot. It had this
single structure:

MC#something#cid#%

It used to change music track to `something`, and the character ID `cid`
was used in clientside muting (blindly trusted, by the way). Then,
this packet was expanded to mean area change as well, so the same
generic structure carried two completely different meanings.

How does one differentiate the two? Whether the client tried to move to
an area `something`, or played a music track called `something`?

The solution was to assume that having ".extension" at the end magically
implied that it was a name of a music file, check the string `something`
within the MC packet, and pray that you guessed correctly. So,
understanding the protocol message required penetrating into one of its
data fields and ambiguously inferring what the whole message even meant.

Modern AO gives us a more logical solution. Not as good as having two
separate packets for two unrelated actions, but we can at least discern
the area and music change directly from the framing.

Area change uses the same two-field structure: MC#area#cid#%

Music change, however, has acquired two additional fields:
MC#music#cid#showname#flags#%

We consider four-field MC to be music change, and two-field MC to be
area change, resolving the ambiguity and eliminating odd constraints
on area and music names.

WebAO still uses the old logic and sends two-field MC packets for both
cases. CSDWASASH server, as a result, thinks that web users try to
change areas when they play music. This commit fixes this behavior and
adds special sendAreaChange instead of using sendMusicChange for both.
The flags are hardcoded to 0 because WebAO can't set fade-in, fade-out,
or position sync, and it ignores the server flags.

Sometimes, WebP icons won't load despite extensions.json clearly
defining it as the only extension used for all image data.

I suspect there's a race condition between fetching extensions.json,
parsing it into client, and checking what extension we should use to get
character icons during loading. Sometimes it correctly loads images,
sometimes it falls back and starts requesting PNG instead.

I couldn't precisely identify where it happens and what's the root
cause. As a workaround, this commit instead makes WebP the
first-priority extension and a fallback.