Request for feature feedback: Support for weaudit files in subdirectories

Hello hello :)

Due to organizational reasons we usually have the code under audit as part of a larger repository which also contains our organizational stuff.
VSCode's language servers tend to behave badly when not opening the root of the source code project. E.g., if we're auditing Go code in one subdirectory, and Rust code in another, opening the project root in VSCode results in language support for neither.

What works is opening the subdirectory, and doing the auditing there.
Unfortunately, that means a lot of switching around repositories when moving the issues to the final report.

As a solution, I've modified the plugin to search subdirectories for all .weaudit files.
Paths in the .weaudit files have the location of the subdirectory (parent of the vscode where the .weaudit resides) prepended, to ensure that all code locations work correctly.
A preview of what it looks like in the file selector is attached, the findings are simply all findings merged.

The downside of this approach is that because loading weaudit files now uses vscode.workspace.findFiles, which caused me to make many of the functions asynchronous.
This also delays delays the tree viewer decorations a bit more at startup.

Would this be an interesting feature to you? Is the asynchronicity a dealbreaker?

I'm the tooling guy in our small team, and with how much we use your awesome plugin it would be cool if I could move my features upstream 😊

Thx much and have a nice day, Alex

The issue does not name files or tests; start by locating the existing .weaudit loading path and its VS Code workspace integration. Review recursive discovery with workspace.findFiles, subdirectory path prefixing, asynchronous loading, and delayed tree decorations. Done would mean the feature scope and async behavior are agreed and subdirectory findings load with correct code locations.