Bug 11336: update hold queue priorities correctly when deleting holds

In various places, deleting a hold request did not trigger recalculating
the priority of the other holds on the bib:

To reproduce the bug:
- select or create 2 users U1 and U2
- select or create an holdable item
- place on hold for both U1 and U2. U1 has priority 1 and U2 has
  priority 2.
- delete the hold for U1
- go on circ/circulation.pl?borrowernumber=XXXX for U2 (or in the DB
  directly) and verify the priority has not been set to 1

The issue is repeatable (at least) on these 2 pages:
 * circ/circulation.pl?borrowernumber=XXXX (tab 'Holds', select "yes"
  in the dropdown list and submit the form)
 * reserve/request.pl?biblionumber=XXXX (click on the red cross)

Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Reran my tests:

Preparations:
- Create holds for different patrons on a record:
  * 1st - title level hold
  * 2nd - item level hold
  * 3rd - title level hold
  * 4th - title level hold
- AllowOnShelfHolds = On/Allow (items were not checked out)

Tests:
Deleted holds from various pages, confirming bugs first,
then testing with applied patches. Reloading database
after each test.

1) Cancel holds from OPAC patron account
  /cgi-bin/koha/opac-user.pl#opac-user-holds
- Cancel 4th - ok, before and after applying the patch
- Cancel 2nd - ok, after applying the patch

2) Cancel hold from holds tab on staff detail page
  /cgi-bin/koha/reserve/request.pl?biblionumber=7

  a) Setting priority to 'del', submitting with 'Update holds'
  - Cancel first (1st) - ok, before and after
  - Cancel hold in the middle (was 3rd) - ok, before and after
  - Cancel last (was 4th) -ok, before and after

  b) Using red X
  - Repeating tests from a) - before the patch is applied holds
    get totally 'out of order' - after applying the patch, it works
    correctly

Additional tests done on this page:
- Change priority using up, down, to top, to bottom icons
- Change priority with 'toggle to lowest'

3) Cancel hold from the patron's account

  a) Check out tab - Delete? Yes, 'Cancel marked holds'
    /cgi-bin/koha/circ/circulation.pl?borrowernumber=X
  - Cancel first (1st) - ok, after applying the patch
  - Cancel hold in the middle (was 3rd) - ok, after applying the patch
  - Cancel last (was 4th) - ok, after applying the patch

  b) Details tab - Delete? yes, 'Cancel marked holds'
    /cgi-bin/koha/members/moremember.pl?borrowernumber=X
  - Cancel first (1st) - ok, after applying the patch
  - Cancel hold in the middle (was 3rd) - ok, after applying the patch
  - Cancel last (was 4th) - ok, after applying the patch

  Without the patch, holds priorities get out of order.

Additional tests done:
- Check in one item to trigger first hold
- Check in one item to trigger second hold
- Check out first item
Priorities are kept while the item is waiting, when it's
checked out, priorities of remaining holds get reset correctly.

Conclusion:
Big improvement, no regressions found.

Passes all tests in t, xt and QA script.
Also: t/db_dependent/Holds.t
      t/db_dependent/HoldsQueue.t
      t/db_dependent/Reserves.t

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11336: (follow-up) fixing capitalization in templates

Fixes capitalization on the holds and check in page.

Changes are easy to spot using:
git diff HEAD^ --color-words=.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11336: (follow-up) correct change to POD for GetReserve()

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11336: (follow-up) improve POD for _FixPriority()

This patch improves the POD for C4::Reserves::_FixPriority()
to (hopefully) describe its function thoroughly.  It also
adjusts the call of _FixPriority() by CancelReserve() to
omit passing reserve_id, since by that point no row in
the reserves table for that request still exists.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>