Munge concerto to include # signs in series facets

Search for "Piano concerto in C major, op. 39" or "Beethoven: concertos
and overtures" and you'll get facets with # signs to assist with fixing
LP # 856811.

Signed-off-by: Dan Scott <dscott@laurentian.ca>
Signed-off-by: Bill Erickson <berick@esilibrary.com>
TPAC: Add search torture tests to concerto record

In addition to # signs causing problems in facets, we found that search
syntax in general is surfaced directly in most links that are exposed to
users in the TPAC. This commit adds several examples to the record with
the title "Trombone concerto (1991)":

In the title, there is an embedded "subject:" search which will be
triggered by autocomplete.

In the author (100 field), there is an embedded "author:" search which
will be triggered from the record details page. This also includes
another usage of the # sign.

In the subject fields, there are:
  * an embedded "subject:" search which will be triggered from the
    facets, autocomplete, and record details page
  * an embedded negation operator which will be triggered from the
    facets, autocomplete, and record details page

Signed-off-by: Dan Scott <dscott@laurentian.ca>
Signed-off-by: Bill Erickson <berick@esilibrary.com>
TPAC: Address some search syntax leaks in links

Expand the list of filtered characters to cover all of the special
characters documented for the Evergreen search grammar
(http://evergreen-ils.org/dokuwiki/doku.php?id=documentation:technical:search_grammar)
when generating links in the TPAC so as to avoid inadvertently launching
filtered searches when a user clicks on something that should just be a
display value.

For example, if a title includes "Presenting a subject: tips for
consultants", it should _not_ launch a search for "subject" containing
"tips for consultants".

This commit addresses most of the link problems in the record
display, as well as the author links in the search results table.

Still problematic are the facets (which seem to rely on exact matching,
such that filtering out the problematic characters is itself
problematic) and autocomplete (which requires modifying the Autocomplete
Dojo widget).

In addition, this commit makes the series code actually display, as it
was using a non-standard method to attempt to return the results from
the BLOCK (and failing). Also, it makes the links for authors in the
record details match the MODS32 definition for personal name parts and
only use the "acdq" subfields. This enables a click on the link to
actually return results; previously, in the case where the author field
included (for example) a subfield "g" value, that value would be
included in the generated link and would likely lead to 0 hits.

For authors, we substitute with a space rather than just eliding the
substituted value. Authors are particularly likely to have dates like
1899-1978; "1899 1978" matches, but "18991978" will not.

Perhaps we should take the same approach with the others, or break down
the search/replace logic a little further (for example, we could remove
the "-" only if it is preceded by a space or is at the start of the
string and is followed immediately by a character, and preserve it if it
is surrounded by digits). But this seems to take us pretty far down the
road of less negatively surprising results.

Signed-off-by: Dan Scott <dscott@laurentian.ca>
Signed-off-by: Bill Erickson <berick@esilibrary.com>