Build process should use a whitelist instead of a blacklist

[hulkrelax]

https://github.com/SteamDeckHomebrew/decky-plugin-database/blob/main/builder/entrypoint.sh currently has a blacklist of things to exclude but this will let files/folders slip in that shouldn't be..

We should instead whitelist files/folders. At a minimum, my understanding is there needs to be a dist folder with index.js and then a plugin.json file. Others may have a python file (not sure if that has to be main.py or not). Honestly it kind of sounds a bit too complicated. Might be just easier to have this process pull in a tagged release from the devs that has everything already built. My repo has a build pipeline that pushes out a zip file of exactly what is needed to install my plugin and it creates a release for it (see https://github.com/hulkrelax/deckfaqs/releases/tag/v1.0.0). Might be something to consider.

[hulkrelax]

This is the first release of System Toolbox. As you can see, a bunch of files not related to the release are included. IMO, it should be a folder like

dist/
  index.js
plugin.json
main.py

The other issue is that the files just get copied into the plugins folder and not into a SDH-SystemToolBox folder

FWIW, all the folders are empty (so the dist folder doesn't even have index.js) which seems like a bug. Similarly, the next release of SystemToolBox just looks like this:

The issue with any whitelist/blacklist is that there may not be a one size fits all solution depending on the requirements of the developer. Seems like it may be better to put the burden on the plugin developer to properly generate a "release" and then consume that.

[TrainDoctor]

This has been largely addressed. If a developer wants to submit a system for plugin developers to submit plugins with package.json specifying what files need to be included with an upload to the store etc then that PR would definitely be a priority. For now the decky-plugin-database CI/CD will determine what files are extract from a plugin before being sent to the store. We're also aiming to build custom backends with this same CI/CD so that users can submit plugins that make use of custom binaries etc.