Rethinking credentials for multiple adaptors

For collections, we need to support multiple adaptor an multiple credentials. Because collections are implemented as an adaptor.

At the moment, I'm sort of fudging this, and saying the engine supports multiple credentials, which get flattened into a single configuration object. It's sort of fine. Or actually I might implement a global credential object which is shared by everything in the workflow. Whatever.

The point is: when there are multiple adaptors on a step, it makes sense that you need multiple credentials.

In the runtime, they need to get flattened to one object, which gives you a problem with name conflicts - especially with stuff like baseUrl an username, which are common. So we need a scoped configuration object, and the runtime needs to pass the right scope into each adaptor function. And this needs to go hand in hand I think with #779 - the config we pass as a second argument to the operation needs to be scoped.

On the execution plan, this may mean that we have { adaptor, credential } pairs in an array called dependencies, or something, rather than the adaptors and credential singletons we have right now.

(quick reminder to me and whoever is reading that the other big problem with multiple adaptors comes from imports: if you use, i don't know, fhir an commcare in one step, and both adptors export fn, which package should we import fn from? Importing fn twice is an error. So basically we need a means of declaring, where there are import conflicts, which to choose.)

Start with the runtime and execution-plan representations described in the issue, then compare the configuration passed to adaptor functions with the scoped configuration requested in #779. Establish acceptance criteria for multiple adaptor/credential pairs, credential name conflicts, and conflicting adaptor imports before implementation.