Rewrite PDFRip to take an Async approach

[Pommaq]

PDFRip currently performs it's tasks with traditional threads causing certain logic to become more cumbersome compared to how I think it could be implemented in an async environment.
This is supported by how engine.rs has seen bugs such as #14 suggesting it's a tad too complicated.

I propose reimplementing PDFRip to be async instead by utilizing the Tokio ecosystem.

The benefits are:

• We have access to Tokio's async runtime, potentially improving performance.
• We have access to tokio-util's CancellationTokens and TaskTrackers as well as Tokio's Select! macro and ctrl-c signal handling.
  • This Could be useful when implementing Feature request: resumable jobs #17.
• We can remove our dependency on Crossbeam and utilize the channels in Tokio.

The current problems that I think need to be resolved are

• We will probably need to make the Producer traits Async, which is supported in rust since 1.75. This is to allow cancelling production of passwords when implementing Feature request: resumable jobs #17 .
• We must lock our minimum rust version to 1.75 if we use async traits.

[Pommaq]

Finally many web frameworks in rust use async functions, which means if we implement a REST api as suggested by me in #18 would require us to do this anyways.