Perserve ordering across public and private calls in accounts entrypoint

[spalladino]

When a user enqueues a batch of calls in their account contract, all private functions get processed first, and all public functions get enqueued afterwards. But this can be a problem if one of the private functions enqueues a public call, since it breaks the expected ordering. For instance, if the user creates a batch with:

1. Enqueue call to public function A
2. Call private function privB (which enqueues a call to public function B)

It'd be expected that A gets processed before B. However, since privB is processed first by the account contract, then B is enqueued before A. This can be confusing to the user. I know first-hand because I just lost over an hour trying to debug an issue #1639 caused by this. And to make it more humilliating it was me who wrote the code account contract entrypoint. Oh well.

Self-rant aside, we should tweak the entrypoint so, instead of receiving two arrays of FunctionCalls (one for private, one for public), it receives a single array of FunctionCalls with a flag indicating whether each is private or public. This requires modifying the entrypoint_payload.ts and entrypoint.nr files. We should also update accordingly the pseudocode for the account contract in the Accounts guide in the docs.

[iAmMichaelConnor]

Thanks for this clear write up.

An attempt to summarise the issue in my own words, to make sure I've grasped it:
Currently, the entrypoint interface doesn't give a user enough freedom to express the ordering of their transaction request. This can lead to public functions being enqueued in the wrong order.
This is an independent problem from us trying to fix the ordering of public function calls which are enqueued by private functions?

How did I do?

[spalladino]

You nailed it, as always :-)

And yes, it's an independent issue. It was uncovered when trying to fix it though.