Azure Functions support

[cgillum]

This PR adds the following:

• A new project for Azure Functions annotations and binding types
• New APIs for implementing and running orchestrations as lambda functions
• Renamed OrchestratorYieldEvent to OrchestratorBlockedEvent, which feels like a more accurate name
• Updates Gradle dependency from 6.8 to 7.4.

Note that in order for the Azure Functions integration to work, two additional things are needed outside of this PR:

1. An updated Java worker that supports trigger return values.
2. An updated Durable Functions extension that supports the newer protobuf serialization format for orchestration trigger inputs and outputs.

In a later PR, I plan to add a simple sample function. Once the above dependencies are available, we can also create a CI workflow that runs the Functions sample end-to-end.

[kaibocai]

This annotation may need to add a another method such as has_implicit_output (if we following python pattern, depending on the way we implement the java worker to support return value in detail. )
same apply to trigger orchestrationTrigger

[cgillum]

I'm cool with that design. 👍🏽

[kaibocai]

LGTM

[kaibocai]

Also @cgillum , I found a library (https://github.com/ReactiveX/RxJava) that is widely used to support asynchronous and event-based programs by using observable sequences. It seems much stronger and more flexible than the Completablefuture in java. Maybe in future, we can try to utilize it to strengthen our durable java functions.

[cgillum]

Agreed we should look at potentially supporting RxJava. It's a 3rd party library, so we may want to consider making it an optional layer that sits on top of this core programming model, but it seems like a promising (no pun intended) idea given how popular it is. Thanks for this suggestion!

[davidmrdavid]

I can't comment on the .gradle files and other declarative-config changes, but this looks good to me as a non-java expert. I left some questions below though

[davidmrdavid]

Can you clarify when we expect to take this path / when the factory would be null? Shouldn't we be error'ing out in this path?

[cgillum]

We will always take this path for Functions since there is no ability for an app to register orchestrators by name. In the case of non-Functions, it depends on whether the app code decides to register a default (*) orchestrator function or not. In those cases, this is a way for users to handle the "orchestrator not found" in their own way instead of just getting an error.