[IMPROVEMENT] Auto-throttle parallel operations

### Please confirm these before moving forward.

- [x] I have searched for my feature proposal and have not found a work-in-progress/duplicate/resolved/discarded issue.
- [x] This improvement refers to an existing feature. If you want to suggest a new feature, please use [this template](https://github.com/marticliment/WingetUI/issues/new?assignees=marticliment&labels=new-feature&projects=&template=feature-request.yml&title=%5BFEATURE+REQUEST%5D+%28Enter+your+description+here%29).
- [x] This improvement is not a bug. If you want to report a bug, please use [this template](https://github.com/marticliment/WingetUI/issues/new?assignees=marticliment&labels=bug&projects=&template=bug-issue.yml&title=%5BBUG%5D+%28Enter+your+description+here%29).

### Describe the improvement

Currently, it seems that UniGetUI treats the parallel operations setting as the only valid number of operations for handling queued items. I'd prefer to see it as an upper limit.

At sufficiently high numbers of parallel operations (which floats between 5 and 50 on my device, depending on the packages being updated) my device gets incredibly slow. I generally see this for PowerShell modules, but also on Pip or WinGet packages.

I propose that UniGetUI can watch the CPU load imposed by its process tree and not add any new parallel ops above a user-settable load threshold, giving the user a way to specify both how many ops can run in parallel as a maximum AND how greedy the process tree can be regarding load.

This can ALSO be used to manage #3615 by starting at one op and then ramping up to the limit imposed by count or CPU load.

### Describe how this improvement could help users

Gives users greater control of both the maximum parallelism and CPU load management. Can be used to manage #3615 as well.