We also rename existing account data methods, explicitly stating that
they're for adding account data.

We "delete" account data by UPDATE'ing any existing account data type to
have a content of "{}". Clients will receive this change as is, which
MSC3391 defines as the method for telling clients that an account data
type has been deleted.

We explicitly don't update rows that already have a content of "{}",
such that we can use the number of update'd rows by the txn to check
whether a delete actually occurred or not. This saves us a replication
request/module API call in the case that it didn't, while retaining
idempotency at the client-facing level.

This comit additionally adds some method docstrings for
simple_update{,_txn}.

Servlet methods, which call handler methods, which call the new storage
methods.

MSC3391 specifies that for backwards compatibility purposes, setting an account data type's content to {}
should be equivalent to deleting that account data. That call should succeed regardless of whether the
account data existed previously or not.

Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>

Doing the filtering in SQL should theoretically be more efficient.