Implement Proper Captcha Token Management

[pr1sm]

Is your feature request related to a problem? Please describe.
#355 has merged and #359 is currently up, but both fail to address an underlying, related issue: Token expiration management.

This wasn't as big of an issue before #359, but now that one-click captchas can potentially be solved automatically, we can harvest quite a bit of tokens after the task manager triggers a harvest. The problem that arises is the expiration of a harvested token. There are only a certain number of one-click captchas that are available before the system gets suspicious and temporarily disables them.

A very real use case would be monitoring on a site that requires a captcha on login and captcha tokens for various checkout steps. If the monitor has to run for longer periods of time before we get to a checkout (i.e. running for restocks), the following steps occur:

1. A captcha required at login triggers the manager to "Start harvesting"
2. We easily harvest a one-click captcha for login
3. We move on to monitoring
   i. BUT: we continue to harvest one-clicks until they run out
   ii. Monitoring takes a long time, meaning all the previously harvested one-clicks are invalid
4. We reach the checkout stage and now require tokens
5. The user has to solve challenges since the one-clicks have expired

This situation effectively wastes the potential pool of easily harvestable captcha tokens because of the gap between when captcha tokens are required.

Describe the solution you'd like
There are a couple of things we need to change to fully address this issue.

Part 1: Create a more efficient (or accurate) method for assigning the harvesting state

We should tighten the "harvesting" state to just when we need it during a task. In my mind this includes 2 groups of when captcha tokens are required: When logging in and during the checkout. If we can have the harvesting state reflect that, we will remove the potential waste of one-click tokens since we will tell captcha windows to stop harvesting during the potentially long monitor stage.

Part 2: Using the token expiration control in the CaptchaWindowManager

Currently we directly pass the harvested tokens to the TaskManager, which has no token expiration logic associated with it. The CaptchaWindowManager itself does have this logic, but because of the bypass, we don't use it at all. Instead of directly listening for the ipc event in the TaskLauncher, the TaskLauncher should look to the CaptchaWindowManager for tokens. This will allow the token expiration control to be in use and prevent errors that occur from invalid tokens being used in requests

Part 3: Add a Captcha Window Harvesting Timeout

In order to prevent the disabling of one-click captchas, we should implement a timeout for harvesting within the CaptchaWindowManager. This would allow a limit of captcha tokens for be harvested (maybe 5-7?) before the CaptchaWindowManager would stop harvesting. This would give the captcha window some time to rest until the 5-7 tokens have been used or are expired. Some more thought will have to go into this, specifically with regards to having the CaptchaWindowManager trigger a restart on the harvesting.

Describe alternatives you've considered
With regards to Part 1 (see above), we could also start/stop harvesting for each time a token is requested. I think this would work, but from a UX perspective, the user could see that start/stop effect on their captcha windows (the captcha challenges rapidly switching). I think having the 2 sections still offers a solution the main gap, but prevents the potential stuttering that could occur if we were to start/stop harvesting on each request.