Modified UserCtrl.adjustedheight() and adjustedwidth() to take a User
parameter because it originally assumed that we were always operating
on the 'showUser'.  However, on the myaccount page, we want to operate
on the 'user' - the currently logged in user
move the add-event/+ sign button over to the right in the "Events"
section
Make user id field hidden
fixed the date field jumping around when you resize the window
app.js:  RegisterCtrl now passes a 'login' parameter set to true when
the user creates his own account.  RestService looks for this
parameter in insertUser, and if it exists, creates a userId cookie. 
So now the brand new user is logged in from the momemt he creates his
account
removed dummied up code in RegisterCtrl that pre-populated the Sign Up
form with data so I could test creating accounts and logging in.
committed the tabbed interface so I can go back to it if I want to
creating events works pretty well now
Editing Events:  Works pretty well now.

Some outstanding items though.
1.  If you delete a participant that has had gifts bought for him/her,
you will delete the record from the circle_participants table but the
records in the recipient table will remain.  So you will have gifts
bought by someone.  That someone won't know the person was removed
(because we don't email anybody yet).  And most importantly, there's
no way to deal with those orphan recipient table entries.  You could
probably add the person back to the circle, since the recipient table
is keyed by circle id and person id, not participant id.

2. If you change the date of an event from active to expired or vice
versa, the interface does not currently put the event in the other
category.  If it was in the active section, it stays there until you
login again or hit refresh.
delete CurrentCtrl - not used anymore
$scope.addparticipant:  added a check to see if index was -1. 
Otherwise, you could end up using a -1 as an array index - not good.
Add Events/Edit Events updated.  Was a little buggy.
When adding people from another circle, include the expired circles
also, since it is common to make this year's xmas circle just like
last year's
Doing away with "Past Events" section (It's still there in this commit
but will be gone in the next.)

The problem with the "Past Events" section is that it would also have
to contain the monstrous code that I use to edit events.  So there's
ddbtn-addcircle.html, mycircles.html and myexpiredcircles.html that
all have very similar code for adding/editing events.

So to keep from repeating all this code a third time, I am doing away
with the separate "Past Events" section.

Now, past events are in the same section as active events.

See User.circleList.  That method used to return just the active
circles.  Now it returns active and past events.  It splits a user's
circles into 2 groups - active and expired.  It sorts the active
events by date with the ascending, so the nearest event is at the top.

The expired events are sorted by date descending so the most recently
expired events are at the top.

The 2 list of circles are then added back to a single list of circles
that is displayed in the "Events" section
Did away with the Past Events section.  Now, there is just one Events
section that shows both active
and expired events.  See User.circleList.
got rid of requirements.txt because they were really tasks.  Moved to
tasks.txt
Send an email to a gift's sender whenever the description changes
Sends email to sender when someone deletes a gift that the sender
bought.
Email when a gift is returned that was previously bought/reserved.

Emails everyone in any circle that is appropriate - not just the event
where the gift was bought - sweet
When determining who to email on returned gifts, exclude the sender -
he's the one who returned the item.  No reason to email him.