LP#1429317 Modify sort of holdings in record view

LP#1429317 Modify sort of holdings in record view

Currenlty, holdings in the record and search resutls are ordered via
their call number.  When searching at a higher org unit, the holdings
are first ordered within org units and then ordered according to call
number.

This commit adds the Library Setting opac.holding_sort_type.  This
setting has three posible options.  The first and default if no correct
option is chosen is 'call', which sorts by call number.  The other two
are 'asc' and 'desc'.  'asc' sorts from the oldest item to the newest
item.  'desc' sorts from the newest item to the oldest item.

In order to make this YAOS work with the Staff Client, the commit adds a
value to the TPAC ctx variable.  The value added is ctx.ws_ou.  This
ensures that the correct setting for the Staff Client's workstation is
used rather than the setting for the org unit being searched.

Move MFHD_SUMMARIZED_SUBFIELDS to Const.pm.  The
MFHD_SUMMARIZED_SUBFIELDS constant is defined in
OpenILS/perl/lib/Application/Serial/OPAC.pm.  It is used in the process
of populating the Issues Held drop down for serial's module records.
This commit also uses this variable with its
rank_serial_copy_by_issuance plpgsql function.  In order to minimize
errors where one version of the variable is updated while another is
left as it currently is, I moved the variable to Const.pm.  The code to
dereference the constant hash reference requires two lines.  It would
be nice if it could be done in one, but I could not figure out the
syntax to dereference a constant.

Added rank_ou_root_search_with_pref_lib SQL function.
This SQL function ranks OUs at the same level unless they belong the
the preferred library entered.  It is meant to be used with a search at
the root level of the org tree, so that all org units will be ordered
alphabetically except the pref_lib and its descendants.

This function is needed to sort holdings correctly when searching at the
Consortial level.  As the code is now, when a search is perforemd at the
Consortial level, the org units are sorted according to their distance
from the Consortial OU.  This results in a confusing listing unless the
reader is aware of the org unit tree layout.

In order to fix this, the commit sorts only by org unit name
(alphabetically) when a consortial search is performed.  However, if the user
has a preferred library set, then the sort needs to rank the preferred
OU and its decendants higher than all others, so this new function,
rank_ou_root_search_with_pref_lib does this.  It is a modified version
of rank_ou, with all but the pref_lib logic cut out.

The sorting of items according to the LS opac.holding_sort_type is done
in a number of ways.  First, records are put into two groups.  Pure
serial module records (a record with assets added only via the serials
module) and all other records.  In some cases, a library may put only
serials module items on a record while another library may put regular
items on a record.  This results in a hybrid record.  Hybrid records are
ordered as if they were regular records instead of serials records.

Pure serials module records are ordered via the data in
serial.materialized_holding_code if either 'asc' or 'desc' are chosen.
All other records are ordered by active date then asset.copy id when
'asc' or 'desc' are chosen.  The copy id is used to maintain order when
items have identical active dates.  This can happen with serials module
records. The copy id is needed to keep the holdings of hybrid records
ordered properly.  Because active_date and copy id are used to order
items in 'asc' and 'desc' orders the previous order which ordered items
within call numbers via their copy statuses no longer works.  Items are
ordered strictly by their age within a collection.

If call is chosen for the LS then all records are ordered in the same
manner with their call number determining their order within their org
unit.  In this case, copy status still applies to the order.  In effect,
using the LS of 'call' retains the current functionality of the TPAC.

The ordering of pure serials module's holdings is done with a plpgsql
function named rank_serial_copy_by_issuance.  This function creates a
number that is used by the SQL copy query to maintain the proper
chronological or enumerrative order.

Finally, there is a small bug in the curent TPAC when browsing through
items in the record view.  If the number of items returned is evenly
divisible by the number of copies per page, then the final page of
items will have a Next link that will take the user to a page with no
items and no links to navigate back to the previous items.  This commit
increases the number of items returned by the query for copies by 1, so
the TPAC can determine if there are more items waiting to be displayed,
and if there are then it shows the Next link.  Otherwise, no Next link
is displayed.

The serial.rank_serial_copy_by_issuance function ranks serials added via
the Serials moduel according to the values in
serial.materialized_holding_code.  It currently causes an internal
server error if an issue is encountered that has a combined month e.g
Jan/Feb or Jun/Jul. In these cases the materialized_holding_code is a
value of 01/02 or 06/07 in the above examples.  The function is looking
for an integer value, and the / in the materialized_holding_code is
causing a Postgresql SQL error, which in turn causes the internal server
error in Evergreen.

This fix looks for the first occurance of a string of digits in
materialized_holding_code and uses that as the value to rank the
issuance.  This should preseve the correct order because Jan/Feb will
use 01, while the next issue if it is March will use 03 and still be
placed after Jan/Feb or before it if the order is descending.  The same
thing will occur with enumerative order.

The only unknown at this point is the possibility of a
materialized_holding_code without a numeric value.  This code takes that
into accout, but uses a default value of 0, which will not help order
the issue, but it will stop internal server errors from occuring.

The possiblity of non-numeric materialized_holding_code values needs to
be investigated.

Signed-off-by: Liam Whalen <liam.whalen@bc.libraries.coop>