fix: DeviceCatalog/DevList/UpdateDeviceList empty device table when packaged as part of a bundled distribution

[hangzqcom]

Problem

DeviceCatalog.exe's device table renders completely empty (0 rows, only column
headers) when this repository is distributed as part of a larger bundled
distribution that installs it under a different product folder name than the
standalone installer. The same root cause also produces the console warning
Failed to open C:/ProgramData/Qualcomm//configurations/devicelist.json from
DevList.exe and UpdateDeviceList.exe.

Root cause

src/libraries/qcommon-console/ConsoleApplicationEnhancements.cpp::applicationDataPath()
only checked a single hardcoded ProgramData folder name (kAppName, i.e. the
standalone installer's own product name) as its fallback when the bin-relative
"../../../../configurations/" path doesn't exist. A downstream distribution that
bundles this repository together with other components under a different product
folder name (staging devicelist.json under
C:\ProgramData\Qualcomm\<BundleName>\configurations\ instead) hits this fallback
and finds nothing. USBDescriptors::load() fails silently when the file can't be
opened (it records an internal _lastError but callers such as
DeviceCatalog.cpp never surface it), so the table is simply left empty with no
error shown to the user.

The bin-relative primary lookup was also fragile: it resolved relative to the
process's current working directory at launch rather than the executable's own
directory, which only worked by coincidence for specific dev-build launch
layouts.

Fix

Rewrites applicationDataPath() to:

1. Walk up from QCoreApplication::applicationDirPath() (not process CWD)
   looking for a sibling configurations folder — fixes the launch-method
   fragility.
2. After checking the standalone installer's own ProgramData folder (unchanged,
   exact prior behavior preserved), generically scan sibling folders under the
   shared Qualcomm ProgramData root for one that actually contains
   devicelist.json, without hardcoding any specific downstream distribution's
   product name.

This directly ports the same fallback-scanning pattern already used successfully
by the sibling EPM repository's epmConfigRoot() for the equivalent problem.

Zero behavior change for the standalone installer path (the standalone
kAppName candidate is preserved unchanged and checked first); this is a pure
additive fix for any bundled-distribution deployment path.

Verification performed

• Rebuilt locally via build.bat — all targets compiled cleanly, no warnings
  introduced.
• Launched the freshly-built DeviceCatalog.exe directly from the dev build
  tree — table populated, confirming the bin-relative path is unaffected.
• Copied the built binaries to an isolated directory with no nearby
  configurations folder (simulating a bundled-distribution install layout),
  staged devicelist.json under an arbitrarily-named sibling ProgramData
  product folder (a name unrelated to kAppName), and confirmed
  DeviceCatalog.exe's table correctly resolves and populates purely via the
  generic scan.
• Confirmed the resolution is genuinely name-agnostic (not accidentally testing
  some other hardcoded path) by temporarily removing every other known
  ProgramData candidate folder from the test machine before re-running the
  above check.
• Confirmed DevList.exe under the same isolated deployment now prints the full
  device catalog instead of failing to open the file.
• Rebuilt a full downstream packaged product end to end from this branch and
  confirmed DeviceCatalog.exe, launched from the real installed product
  location, shows a fully populated device table.

No changes were made to any packaging/build tooling outside this repository —
the fix is entirely contained in this one function.