Fix Ion Auth having wrong default user group

The group that all users should belong to is called "users", not
"members". This was causing new user accounts to get assigned
to incorrect groups when created via the Ion Auth create_user
form.
Add project admin CRUD (proof of concept)

There are only two fields in here for now, so this is more of a
proof of concept than an actual working CRUD form. I mean, it
does work -- it can create, update and delete records from the
projects collection (I know Mongo calls them "documents", but
I find the term "records" to be less likely to cause confusion with
HTML documents). But actual projects will need several more
fields, as well as the ability to manipulate user records within
the admin interface. Once we set up the final admin interface,
we'll know what fields are needed in actual project records and
we'll be able to make the appropriate adjustments here.

I'm not completely happy with the directives.js yet; it could
probably use a rewrite to make it more modular, the way I
did with controller.js. And the same goes for sf.php: too much
copy-pasted code in there as well. I'll have to look into PHP's
introspection capabilities and see how much I can do with them.
Switch admin app to do project CRUD ...

(I'll be reverting this commit with my next one; this is just to
put a "how to do it" commit into the git repo. Because when I
first switched this, I forgot to switch UserCtrl to ProjectCtrl
and then spent quite a bit of debugging time wondering why no
records were being created in the projects collection.)
... and switch it back to do user CRUD again.

This reverts commit 59d27254e0988a6013ce864ace0887a82210cd4b.
Fix nasty subtle bug in PHP object-orientation

Basically, PHP's object-orientation is a bit bolted on, and it
shows occasionally. For example, here we needed to use the
static::$variable form (new in PHP 5.3) instead of self::$variable,
because self::$variable will *always* refer to the parent class's
version of a static variable instead of the child class's version,
even if the child class(es) is/are *supposed* to have different
values in the variable from the parent. But with static::$variable,
the child class(es) can actually look up their own version of
the variable and it will work. (I'm not really explaining this too
well, because I don't fully understand it myself yet).

What this was causing was a nasty bug where the $_mapper
variable of User_model classes and Project_model classes would
both be the same: whichever one got initialized last would
clobber the other one. So when I thought I was loading up data
from the users collection via a JSON-RPC call to user_list(), I
was actually getting data from the projects collection instead.
Or, if I switched the order of the $CI->load->model("foo") calls
in sf.php so that User_model was loading after Project_model,
then vice versa would happen: I'd call project_list() but would
get results from the users collection.

Switching everything in Mongo_store.php to use static:: instead
of self:: seems to have solved the problem. Hopefully it won't
come back.

For more details on the difference between self and static, see:
http://joshduck.com/blog/2010/03/19/exploring-phps-static-scoping/