Fixes #15443

The problem was that locateRunfiles behaves differently depending on how the current executable was built:

• When the executable is a bazel run or bazel test target, it returns the input prefixed by the runfiles directory assigned by Bazel for that target
• When it's a packaged app produced with bazel_tools/packaging/packaging.bzl, locateRunfiles ignores the argument and returns the "resources" directory, a sibling of the packaged executable.

One of the changes from #15290 was using a rules file instead of a rules directory expected to contain a dlint.yaml file. Since the tests always use runfiles, they worked fine, but in Daml Studio it meant the locateRunfiles call with the dlint.yaml file returned a directory.

We'd had similar problems before due to the unexpected behavior of locateRunfiles, see #8278 (comment). Each time we resorted to workarounds using locateRunfiles to find a base directory and then appending the filename - which only worked because in packaged apps the file was stored directly in the "resources" directory.

The fix proposed here makes the two resolution mechanisms explicit by introducing a new function locateResource which takes one path to use for each mechanism. All the uses of locateRunfiles outside of tests or compatibility/ have been replaced with locateResource, removing the workarounds described above.

EDIT: additionally, this PR adds an hlint warning recommending locateResource instead of locateRunfiles - which can be disabled when the codepath is never used by a packaged application. Also, locateRunfiles now simply crashes when used from a packaged application (instead of returning the EXECUTABLE/../resources directory).