The filter implementation of Trac's query module was used as a guide.
We won't care for banned accounts by default, just active ones and these
marked as pending for approval, on registration time and via the email
verification process, if enabled.

This could help a bit with rendering performance of the user admin panel too,
i.e. if you accumulate many banned accounts over time.

I added least intrusive translation support for the confirmation message as
done for single (own) user account deletion in AccountModule before, so it
won't require message extraction from JS code itself.

Adding the registration approval configuration option to config admin panel.
Taking care for marking all potential message parts for translation as well.
A recent suggestion by Ryan J Ollos is merged in here too, so that all kinds
of restricted accounts are clearly visible in user listings now.

While simple, this might be an effective counter-measure against spammer
registrations, because intentionally it's rather hard to spot the difference
between an approved authenticated session and one with pending approval.
So I forsee more wasted resources on attacker's side to figure out, why
one still fails to spam the site even after successful registration, and
that is certainly a good thing.

Note: Due to its implementation banning is instantly effective and will
prevent even authenticated sessions from doing more than a user could in an
anonymous session, unlike the account lock provided by AccountGuard.
That wouldn't prevent authenticated sessions from continuing indefinitely,
at least until next authentication time, and this might be a rather long time,
if persistant sessions had been allowed before.

Note, that any previous version of TracAnnouncer won't work with latestAccountManagerPlugin 'trunk' code, and this already made me thinking about
a more robust change listener definition. But this is another subject.