This caused the code to miss some English translations on the (mostly
German) FSCDC web site.

If a registration's state changes, we offer to send an e-mail message
according to the new state, based on the `mail_STATE_LANGUAGE.txt`
template (falling back to `mail_STATE.txt`, or
`mail_generic_LANGUAGE.txt`, or `mail_generic.txt`, in that order).

This lets us go back to the participants list without actually sending
e-mail. It makes sense to have the buttons in the HTML template for
easier maintenance.

This is a hack to accommodate `www-next.rscdsvienna.strathspey.org`,
which we need to use because we don't control `rscdsvienna.org` and
therefore can't install `www-next.rscdsvienna.org` for the testing
site.

`EXTRA_ACE4_DOMAINS` can optionally contain a comma-separated list of
domains that the system should accept requests for.

This checks whether the account name, IBAN, and BIC are non-empty and
whether the IBAN looks plausible as far as IBAN rules are
concerned. (If more countries join both SEPA and the SCD community the
IBAN-length-per-country table in `ace4.utils.iban` may have to be
tweaked.)

We can't index into zip objects (which are generators). The lists are
generally short so there is little value in hanging on to the generator.

When an address is required, the country on an event registration form
used to default to “Afghanistan”. As far as we're aware, there are no
Scottish country dancers in Afghanistan, but who knows? It doesn't
make a great default value, so unless we know better (e.g., from the
profile data of a logged-in Strathspey user), we default to the
country where the event takes place, based on the assumption that
participants are likely local.

Another possible approach would be to try to figure out the default
from the user's IP address, but this is too much hassle for now.

Validation is based on IDs, so using the ISO code, while more
mnemonic, doesn't work.

Ensure that resources without objects can have objects created, and
that objects have an owner.

This didn't set the `initial` attribute to the form constructor and
therefore changes made in the form weren't stored in an existing
record.

Lists must have an owner, so we can't let anonymous users create
result lists. (In fact the code would crash before this fix.)

Especially if no collection has been specified.

The event venue form didn't have a properly initialised event and so
the venue wasn't stored correctly.

For authenticated users.

… for a list name that doesn't depend on the date.

This is a little tricky because we do want to rewrite the list name
according to the template when the *template* changes. The list name
is supposed to stay unchanged especially when the user has changed the
list name already and is now changing the date.

This was apparently overlooked. [Murrough Landon]

The original implementation of exact search searched the alias models
as part of the original query, but we're now using a different
mechanism that is compatible with the approach taken for trigram
search. This means that the alias model must be removed from the
original query.

This is supposed to make it easier to use GET requests to do quick
searches. That way, we can use simple `<a>` elements to allow people
to repeat an exact search as a trigram search and vice versa.

[Suggested by Ian Brockbank.]