Add support for line item options

This adds a foreign key from Transfer to LineItemOptions (as suggested by Jordan in #1119) and updates the accounting controller and StudentExtraCosts module to make use of it.  You can test this by creating new line item types for a program; you can add options (each with a description and optionally a new cost value) from the admin page for the line item type.  You should see each of these options on the extra costs page in student reg, and it should remember your choices when you save and come back later.

Addresses #1119 and #1120.  However, it could be argued that more front-end work is desirable for #1120.  Also, we don't support a combination of multiple LineItemOptions choices and variable quantity (in the StudentExtraCosts module; the accounting controller should be able to handle it).

Hmm, we need to be a bit careful here. This code relies on the fact that ```get_preferences()``` is only going to return at most one item for each line item type. But that relies on us having called ```set_preference()``` and ```apply_preferences()``` in such a way that there is at most one (line item, amount, option) tuple for each line item stored in the database. Which is true in our current system, but could be false if we introduce a bug which breaks that assumption, or if we in the future build support for, say, checkbox options (whereas now we only have select-at-most-one radio button options).

If we want to enforce select-at-most-one, then perhaps we should do that more strongly. The ```delete()``` statements that I commented on earlier, maybe we should only be deleting by line item, and compressing those four possible conditions into one. After all, we don't currently support having Transactions with the same line item but differing amounts or options. And we can probably also optimize ```get_preferences()``` and ```apply_preferences()``` according to this constraint as well.

Or we can leave ourselves open to the possibility of checkbox options in the future, in which case we need to fix this part of the code, or leave some TODO comments in a few places to remind ourselves that we'll need to make some fixes if we relax our assumptions in the future.