Remove Reactor (Mono) and use CompletableFuture

## Describe the proposal

Before Project Reactor, I used CompletableFuture for async programming in Java. When writing the first complete version for this SDK, Project Reactor was the recommended async programming model - it was (probably still is) used by the Azure's Java SDK.

Based on my experience in the last few years and a few in person conversations about Project Reactor, I would like to propose this SDK to move into using CompletableFuture. For me, my biggest problem with Project Reactor is how it completely changes the programming model for Java, having a sub-syntax of its own, while also forcing apps that don't want to use Project Reactor to have this dependency forced on them if they want to use Dapr with Java. It means a new interface, not depending on Project Reactor at all, keeping the existing implementation for 2 releases (deprecation path for the Dapr Project).

For projects that depend on the current interface and don't want to change any code (like wrapping CompletableFuture into a Mono object), we can still offer the existing interface via a new artifact (dapr-sdk-reactor, or some similar name).

In summary, these are the benefits for this change (in order of importance):
1. Apps that don't want to use Project Reactor, will not be forced to use it or even have it as a dependency.
2. Apps that want to operate as-is, will still have a path forward, requiring just to add a new dependency to their pom.xml file and all the CompletableFuture interfaces will be available as wrapped inside a Mono.
3. Lower barrier of entry to contribute, since people that are not familiar with Reactor can contribute without having to re-learn a new "language".
4. Simplify the SDK's code readability and debugging.

What does the community think about this change? Please, react (pun not intended) to vote:
👍 We need this ASAP.
👎 Let's keep it as-is today.
😕 Need more time to think.

PS: I know this can be a controversial proposal as I have heard passionate opinions both ways on this matter.

La proposta non indica file, test o punti di ingresso; iniziate individuando le interfacce pubbliche Reactor/Mono del Java SDK e le relative implementazioni. Valutate l'ambito di un'API CompletableFuture, il percorso di deprecazione distribuito su due release e un artefatto reactor separato, quindi definite test di compatibilità e ottenete una decisione della community prima dell'implementazione.

Scritto dal modello di indicizzazione a partire dal testo della issue.