feat(UI): New progress bar

[Fennerr]

Context
Improved UI for prowler 4.0

Currently only supports the AWS provider.

Description
Switched from using alive_progress bar to using Rich to display the UI

I wanted to implement the new ui without having to update the service class's or checks code.

I was able to do it for the service classes, by modifying the threading_call to initialize the progress bar with X number of tasks (length of the iterator passed to the function), and increment the progress bar as each thread completes it's task.

There is also a progress_decorator to be used where threading_call is not appropriate - like for global services (see list_distributions in the CloudFront service)

Doing checks was not as straightforward, as the logic for the way checks are handled is coded into the execute function, so I couldnt do anything at the base class level. For the most part, checks are really quick, and dont need a progress bar. One place where it could be appropriate, where it does take a long time to execute, was the secrets check for lambda functions (other secrets check are also likely to take a decent amount of time and could benefit from a progress bar)

In these cases, inside the execute function, a call to self.start_task needs to be made with the display message and the number of tasks (self.start_task("Processing functions...", len(functions)) for checking secrets in lambda code). Then after completing an item in the list of items to check, a call to self.increment_task_progress() needs to be made. At the end of the check, just after returning the findings, I made a call to self.update_title_with_findings(findings) so that the UI shows X/Y failed the test. I like how it looks, but it requires some changes to be made to the checks which is what I was trying to avoid - but couldn't find a way around this.

I have also implemented an execution_manager. I thought I had previously pushed a branch with this change, but it doesnt seem to be the case. The execution_manager was made to help be more deliberate about which clients are intialized, then run all the checks that use that client, and then release the client for it to be garage collected.

It determines what clients are going to be imported by all the checks that are going to run (by using /check_to_client_mapper.py. It then starts running through the checks, and will handle initializing any clients needed by the check. It will then prioritize the next check based off of what clients are already loaded, and release the clients once they are no longer needed.

I have also implemented the --only-logs functionality - in which case the live display is not intialized.

This pull request is a WIP, but wanted to provide it so longer so it's easier to see the diff between main and what I have done.

I still need to complete changing the functions inside the service init's to make use of threading_call or progress_decorator, and any other feedback provided.