Add ability to watermark preview PDFs in the invoice system
Add support for rendering receipts, and not just invoices
Minimal typo fix
Fix comment, so it doesn't show up in greps for incomplete things
Ignore all compiled python files across the whole repo
Include the 1901 information on receipts as well

Just not the bank transfer information
Add a simple mail queue in the database

Adds a function to call that will render a complete MIME message, and
write the resulting text to a database table.

Then there is a cron job that runs at regular intervals (every 5 mins or so)
and sends all the queued emails.

This brings in two important functions:
 * The ability to "send" emails from regular web views without the risk of ending
   up blocking on the SMTP server.
 * The abilitty to "transactionally send email" - meaning that mail sen this way
   will just disappear if the transaction (normally managed by django) that's open
   when it was sent ends up rolling back. This prevents re-sending email over and
   over again when some later step in the process fails.
Create a new decorator, @user_passes_test_or_error

The normal decorator can end up sending the user in an infinte loop due
to the community auth system. This one will just give "access denied" when
the user is logged in and does not have permissions, rather than allow
the user to log in again (which will just be with the same user anyway)
Deprecate the old invoicing system

But we leave it around so we can download old invoices
New generation of the invoicing system

This invoice system is designed to be much more than just an invoice generator.
At the core is a more API-based invoice generation, and it has a much easier
to work with interface as well. Let's consider the last version a prototype.

* Supports tracking which invoices are paid
* Supports automatically flagging invoices as paid based on API
  (paypal is the obvious, but it's abstracted to support others as well)
* Supports creation of invoices via internal API, such as conference registrations
* Supports in-place editing and saving of temporary invoices while built up
* Supports connecting an invoice to a community account (not mandatory), making
  it possible for a user to view all their invoices historically
* Automatically generates receipts for all paid invoices. If a community account
  is registered they will be viewable on the web, and as long as an email address
  is registered, it will also be emailed to that.

The idea is that this will act as a hub for *all* payment processing, instead of
having it piece by piece in the different other apps.
Add paypal invoice processor, reimplement paypal matching on top of this

This makes our paypal account now automatically flag all regular invoices as
paid, and removes support for membership and conference registrations. These
will soon be reimplemented on top of the new invoicing system as well, but
until that is done they will not be processed.
Add an invoice payment processor for bank transfer

This processor simply generates a HTML page with bank transfer details.
There is currently no support for polling the bank for actual transactions,
so all matching has to be done manually. (Lack of API from the banks side, of course)
Properly add a return URL when starting payments from the list of invoices
Reimplement membership payments on top of new invoice management code
Company name shouldn't be required
Use a different receiver email as well, when testing paypal sandbox
Reimplement conference invoicing on top of new invoicing system

Removes some code in favor of the shared version, and also changes the
flow for conference registration in a few ways:

* Going to payment from the registration is now a two step process. The first
  one generates an invoice, the second one pays the invoice.
* Once the invoice is generated, the registration is locked and can no longer be
  changed in any way. This should prevent users from changing their details
  after actually paying - usually by trying to register somebody else without
  logging out.
* Everybody now gets an invoice in their registration, and a receipt once it
  has been paid. This removes the manual step of generating an invoice for those
  who request it.
* Payment with voucher is now a separate step, that does *not* generate an invoice,
  since there really is no invoice in this case. Instead, just like before, the
  registration gets immediately approved if the voucher is valid.

Some more CSS and general styling work is definitely needed, but this completes
the functionality.
No need to pass along payoptions in confreg anymore

The whole concept of the confreg specific payment options should be removed
in the future, but let's leave it around for a while.
Implement a paypal PDT receiver

This means that the payment flow comes right back from paypal, and we can
flag the invoice as paid as the users browser gets there. We'll then redirect
back to the invoice specification or conference registration as part of the
same workflow, so no manual refreshes are required.
Rewrite SSL redirection code

Now uses a decorator instead of manual checks inside each view.

Also add SSL decorators to the new invoice and paypal code to make sure
it's served over SSL.

Finally, define two new settings for SITEBASE and SITEBASE_SSL to override
the website names in a local sandbox install. Makes it possible to for example
test the full paypal workflow, since we need to be able to pass an actual
working URL to paypal in that case.