Allow per-library fallback LAL data path for XLALFileResolvePathLong()

Description

Detailed description of the changes, why they are being made, etc... Also indicate appropriate tickets and tests that have been run to determine that the changes work as intended and do not introduce other problems.

API Changes and Justification

• XLALFileResolvePathLong() replaces fallbackdir with fallbackpath
  • May contain either absolute or relative (to liblalsupport.so) paths
• LALSUITE_WITH_FALLBACK_DATA_PATH (replaces LAL_WITH_DATA_PATH) defines LAL_FALLBACK_DATA_PATH to fallback LAL data path
  • Defaults to $(pkgdatadir), same as for fallbackdir argument
• New macro XLAL_FILE_RESOLVE_PATH() passes LAL_FALLBACK_DATA_PATH to XLALFileResolvePathLong(), so each library gets its own fallback path
  • Not designed to be used outside of LALSuite; libraries implement their own functions (e.g. XLALReadEphemerisFile(), XLALSimReadDataFileOpen()) which call XLAL_FILE_RESOLVE_PATH() internally
• Non-inline XLALFileResolvePath() and XLALPulsarFileResolvePath() wrappers kept to avoid breaking ABI
• .gitlab-ci.yml: add finding data files test to lalpulsar_longtests

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

If any of the Backwards Incompatible check boxes are ticked please provide a justification why this change is necessary and why it needs to be done in a backwards incompatible way.

Review Status

n/a p