LAL: new functions for LALString, UserInput, Window modules

Description

A few new LAL functions I need for future MRs:

• LALString: add functions XLALStringTranslate() and XLALString{Strip|Keep}Chars()
  • XLALStringTranslate() performs general translation/delection a la tr
  • XLALString{Strip|Keep}() uses XLALStringTranslate() to strip/keep characters matching a predicate, suitable for use with ctype.h isalnum() etc. functions
  • XLALStringReplaceChar() reimplemented using XLALStringTranslate()
  • Add tests to LALStringTest.c
• UserInput:
  • If a user variable is marked DEFUNCT (i.e. it is no longer functional, and kept solely to issue a warning to anyone who tried to use it) allow the C variable the command-line parsing code points to to be NULL. This means you can then remove the C variable completely, and just register the defunct warning using e.g. XLALRegisterNamedUvar(NULL, "defunct-option", ..., DEFUNCT, "This no longer works")
  • Add option to control whether to skip unset variables in logging the command line by XLALUserVarGetLog(). By default variables not given by the user on the command line (where a default value is then presumed) are not included in logging the command line used. But that means the log is incomplete as it does not record the default values (which may change over time). To get the full log I've added a new function XLALUserVarGetLogEx() which extends the interface of XLALUserVarGetLog() and allow one to specify whether unset variables are included. The default behaviour of XLALUserVarGetLog() is preserved.
• Window: add function XLALCheckNamedWindow() for checking names/parameters. This is a useful function for checking whether a named window is defined before actually creating the window (cf. !2005 (closed)). It checks whether a window exists, and checks for consistency between the haveBeta argument (which asserts whether the user supplied a window parameter) and whether the window actually requires a parameter.

API Changes and Justification

Backwards Compatible Changes

• This change does not modify any class/function/struct/type definitions in a public C header file or any Python class/function definitions
• This change adds new classes/functions/structs/types to a public C header file or Python module

Backwards Incompatible Changes

• This change modifies an existing class/function/struct/type definition in a public C header file or Python module
• This change removes an existing class/function/struct/type from a public C header file or Python module

Review Status

cc @adam-mercer @jolien-creighton for review

cc @david-keitel for possible interest re. the UserInput and Window changes