Registraion module and email template, invoice module

Started work on the registration feedback loop. Edited the auctions to
have a list of registered users and edited the db create and update
calls to support this. The auction view was also updated to support
registering per auction and displaying the registration status for users
already registered.

The registration task has been split out into its own module as well as
the invoicing module. The winner's task is not using this invoice module
yet. The registration email template was also written to be used with
the registration task.

Each auction displays a button to register the current user with this
auction. Upon clicking the button, the user is added to the current
auction object with a registration status and registered property. An
invoice for the registration fee is created along with a BasicPay
Receipt and the link to the invoice is emailed to the user.

Updated the site's routes and seed file to support registrations.

Webhooks for both the winner's invoice and the registration invoice are
still needed as well as fixing the redirect routes for registration. The
registration view needs to be updated as well.
One Time Registration and registered users

Updated the Registration Feedback loop so that it's a one time
registration fee instead of a fee per auction. This included updating
adding a registeredUser object into the DB each time a user starts the
registration process. The DB calls to upsert and retrieve
registeredUsers were also create. A Emcee model was created to easily
and consistently retrieve the registeredUser object from the DB

The registration email template, auction view, and registration views
(error and success), were updated to reflect the changes above.

Modifications to the registration and invoice modules were also
necessary due to the way the invoices for registration fee are now
different. A auction isn't reference in the invoice so that has been
pulled out of those modules.

The auction, bid, and registration routes have all been updated to check
for a registeredUser for some of their actions. Auctions will not show
bidding controls if the user is not registered but will show either a
registration status or the option to register if they have not already.
The bid route will now reject bids if the user is not registered. The
registration route will only allow a user to register once and redirect
to a instructions page or otherwise to an error page showing the user a
relevant error ("User already Registered", "No User Found", etc.)

Lastly, the registration route was moved from /sb/auction/registration
to just /registration.
Registration and notify winners webhook

Created the webhooks for Basic Pay to call when the payments for both
registration and auction winner are verified. In both cases, an email is
sent to an admin stating that the payment for either case has been made.
In the registration case, the user is also allowed to make bids on
auctions. Email templates for both cases were also created.·

The BPReceipt object in the DB needed to be modified to use a user's
userId instead of their username. The same change needs to be done for
both ads and bids.·

A few more configurations were added, mainly the base URL for the site
itself to be used in both emails to the admin as well as for the
webhooks in BasicPay.
u:wqserId, admin email, auction closing

Renamed the cull-auctions resque job to auction closing to better
describe what it's actually doing. Also, refactored the code in auction
closing to use the invoice module instead of having its own version of
that code.

Removed all instances of hard coded emails from the code. Made the admin
email address and the mailer sender email address a configuration
option. Updated the code to use these configuration options instead of
the hardcoded addresses.

Updated both the ad and bid DB models to use the userId as the key
constraint rather than using the username. The reason for this is
because usernames are trasient in some system and can be changed. UserId
should be a value that is permanently assigned to a user.

Lastly, removed the admin property on the user object before it is saved
in the bid DB object model. Although this isn't a security risk, it's
just the right thing to do.