Remove the default engine behavior in internal applicative eval functions

[joaopluigi]

Context

Following a change #38 in how dependencies are provided, services importing Nodely (indirectly through nodely-helpers) began facing errors. This occurred because services were not explicitly providing promesa as a dependency, even if they were not using it.

The issue stemmed from Nodely's applicative engine eval functions, which would default to using the promesa engine if no engine was specified. This resulted in promesa being included as a required dependency.

Since applicative eval functions are intended for internal use only and are accessed through the API, which sets the core-async engine when no engine is provided, the decision was made to remove the behavior of having a default engine at applicative eval functions.

[aredington]

Going from providing a 2-arity and a 3-arity to only providing a 3-arity signature is a breaking change: clients who called the 2-arity version get failed when they were supported in the past.

Could we make an applicative engine that didn't rely on promesa lib (or any other of our optional libs) and continued to support the 2-arity version?

[joaopluigi]

Going from providing a 2-arity and a 3-arity to only providing a 3-arity signature is a breaking change: clients who called the 2-arity version get failed when they were supported in the past.

Could we make an applicative engine that didn't rely on promesa lib (or any other of our optional libs) and continued to support the 2-arity version?

I converted the PR to draft, so we can still work on that