Add an option to "macdeployqt" which decides which way the dylib install names should be specified (@rpath vs others)

Problem description

Typically, install names for bundled libraries are specified in one of these ways:

1. Path relative to executable (@executable_path, @loader_path).
2. Path relative to LC_RPATH (@rpath).

It appears that @executable_path/@loader_path approach still has valid use cases (see https://codereview.qt-project.org/#/c/138349). However for common applications, @rpath is generally easier to read and less problematic.

The "macdeployqt" tool is capable of doing both (note bug QTBUG-75762 though). It is unclear to me on what basis it decides whether to go with one or another. I suspect the "-no-rpath" option which can be passed to the "configure" script when building Qt from source.

Suggestion

All above lead me to a conclusion that user should be able to decide which install names strategy is best suitable for given project, regardless of Qt installation settings. Therefore, I suggest implementing one of following:

1. Adding two CLI options to the "macdeployqt" tool: "-rpath" and "-no-rpath", which override default choice made by this tool.
2. Adding one CLI option to the "macdeployqt" tool: "-no-rpath", which disables @rpath approach. That implies that @rpath approach is used by default, which is probably a breaking change. Note that maintainers of Homebrew Qt package seem to rely on current behaviour.
3. Add some QMake variable which defines which approach is suitable for project.

Side notes

1. Fixing that will make QTBUG-75762 far less serious, as that bug does not occur when @rpath approach is used.
2. cc sorvig who is assigned to above ticket.