Avatar backends provided by extensions had a tendency to disappear

periodically from the enabled list, with the default backend being unset

as well. This was the result of the AvatarServiceRegistry attempting

to self-manage the settings a bit too closely, checking during

population and attribute accessors for whether stored IDs make sense

with regards to the currently-populated backends and erasing IDs that

don't currently map.
This meant that any IDs pertaining to backends owned by an extension

that hadn't yet initialized hooks could be lost when certain operations

were performed, with the data being erased from settings. Along with

this, shutting down an extension (such as during extension manager

reload or when shutting down an Apache thread) would unregister the

backend, which would also remove the enabled/default backend IDs.
The fix is to simplify the accessors, population, and unregistration,

removing these side effects. IDs stored in settings are no longer

removed unless explicitly requested by disabling a matching backend

(which can now be done based on the ID instead of the class) or changing

the default backend. Otherwise, they're preserved and loading takes into

account that these just might not be available yet.
This means that code can attempt to look up the default backend class or

the list of enabled backend classes before an extension registers a

backend, and then after registration, and the former information will

exclude the registered class but the latter will include it, without

having to repopulate. It also means that the former will be returned

after disabling the extension, but that the latter will once again be

returned after re-enabling.
If an administrator re-saves the list of enabled avatar backends and the

default backend from the administration UI, the new settings will no

longer include any unregistered backends, which will keep settings from

forever including backends from every extension ever loaded.
Unit tests have been updated to test for this and to make some parts

more clear. There's also some improvements to documentation with the

registry that was noted while documenting new methods and building docs.

Added a custom backend, verified it was available in Avatar Settings.

Made it the default and enabled it. Then I removed that custom backend

and accessed pages, including Avatar Settings. Saw that I got log

messages about this not being available, but no crash. The backend wans't

being shown in the list of available backends anymore. However, it was

still listed in the siteconfig settings payload.
Re-enabled the backend and saw that it was once again working and

available in Avatar Settings.
Re-disabled and saved Avatar Settings. Saw that the IDs were removed

from siteconfig.
Unit tests pass.