Standalone user registration flow and ACLs

This is a description of how standalone user registration should work, some of which is currently implemented and some of which is not:

1st user in the system:

Registers during installation (works, most of the time, but I've run into some bugs with it lately; needs more testing), gives an OpenID to login with, and is added as admin user (currently this happens, but it should happen via adding the first user to the Administrators group, which does not happen).

Subsequent users:

Admin user adds a contact, associates OpenID with it, and then sets their "Allowed to login" bit. All that is currently present and working. However, by default new users shouldn't be added to any groups (currently the case), which should translate into their having no privileges not assigned to the "authenticated" ACL role (currently they seem to have full admin access, though they are not in the Administrators group).

Note about CIVICRM_ALLOW_ALL:

You can define CIVICRM_ALLOW_ALL as true in your civicrm.settings.php file and it will start allowing any valid OpenID to login to the system. This was created to support demos of standalone, and is currently enabled on standalone.demo.civicrm.org. These users do not exist as contacts in the system (most of the time), and they should have similar privileges as the demo/demo user on Drupal demo installations. This would never be used in a production installation, so it's not a high priority, but if there were a way to "sandbox" any users that logged in this way such that they could only see data created by another demo user, that would be ideal from a security perspective. This prevents a careless admin from exposing all her data by adding this define to her settings file (maybe because she copied and pasted w/o reading thoroughly, for example). That may be more effort than it's worth, however.