Bug 10401: Add ability to merge invoices

Given how easy it is to accidentally receive items from one invoice on
multiple invoices, the ability to merge invoices can be quite handy.
This patch adds that ability to Koha's Acquisitions module.

To test:
1) Apply patch.
2) Run unit test:
    > prove t/db_dependent/Acquisition/Invoices.t
3) Create two invoices from the same vendor for merging, and receive at
   least one order on each.
4) Do a search on the Invoices page that brings up both the invoices you
   created.
5) Check the boxes next to the two invoices.
6) Click "Merge selected invoices."
7) Choose which invoice you want to keep (the default will be the first).
8) Click "Merge."
9) Confirm that the resulting invoice has all the orders you received
   listed on it.
10) Sign off.
Bug 10402: Use an object for contacts

In preparation for adding the ability to handle multiple contacts, this
patch moves booksellers' contacts into their own class,
C4::Bookseller::Contact.

To test:
1) Apply patch.
2) Run database update.
3) Edit a bookseller, making sure to add a contact.
4) View the bookseller's information, making sure the contact
   information is there.
5) Run the unit test:
    > prove t/db_dependent/Bookseller.t
Bug 10402: Move contacts to separate table

This patch normalizes the data structures used for bookseller
contacts.

To test:
1) Repeat tests described on previous patch.
Bug 10402: Add ability to enter multiple contacts

Some vendors may have more than one contact. For example, a technical
contact and a billing contact, or a contact for journals and a contact
for monographs. Rather than require that each contact be either made
into a separate vendor or recorded somewhere outside of Koha, it would
be really useful of Koha had the ability to add multiple additional
contacts to vendors in the Acquisitions module.

To test:
1) Apply patch.
2) Edit a bookseller, making sure to add a contact.
3) View the bookseller's information, making sure the contact
   information is there.
4) Run the unit test:
    > prove t/db_dependent/Bookseller.t
5) Add multiple contacts to a vendor, see that they show up.
6) Delete one contact from a vendor with multiple contacts,
   see that the result is correct.
7) Sign off.

Note: This test plan can supersede that on the previous two patches,
as all functionality of the previous two patches is required by this
one.
Bug 10403: add ability to change fund on receipt

Right now there is no way to change the budget or fund when receiving an
item, which is annoying, particularly at the end of the fiscal year when
every item not already received has to be switched to the following
year's budget. This patch adds the ability to change the budget and fund
when receiving.

To test:
1) Apply patch.
2) Create an order for a vendor, choosing a fund to use for that order.
3) Receive the order, leaving the fund unchanged. Make sure the fund
   did not change.
4) Create another order for a vendor, choosing a fund to use for that
   order.
5) Receive the order, this time changing the fund. Make sure the fund
   is changed.
6) Run the unit test:
    > prove t/db_dependent/Acquisition.t
7) Sign off.

(Notes: this patch depends on the Acquisitions.t unit test improvements
in bug 10274; the seemingly-unrelated change in SQLHelper quiets an
irritating warning caused by the NewOrder call in ModReceiveOrder)
Bug 10403: Show inactive but unlocked budgets on orderreceive

I have heard from several libraries that at the end of the budget
year even though a budget is inactive for new acquisitions, an
inactive budget should remain modifiable until the books are
closed and the budget is marked inactive. This patch makes it so
that all budgets that are unlocked are available on the order
receipt page (only).