Support wasi:config/store in worker executor

[mschuwalow]

resolves #1227

More interesting tests will be added as I add support for wasi:config in the component service.
Went for a slightly different approach than with env vars. Instead of persisting in the oplog. The goal is to make them fully reproducible based on the oplog, similar to the ifs.
If this ends up looking nice I would like to switch env vars to use the same setup.

[vigoo]

I was thinking about the high level approach, and wanted to point out one thing that I'm undecided whether it is a problem or not.
If we do this in the "usual" way of treating the get-config(key) function as a durable function, it means every time the worker accesses a configuration key, we have a corresponding oplog entry with information stored about both the key and the value.
With your method there is no oplog entry about the configuration access at all, but I guess the config map is part of the initial create entry, and successful update entries (did not check the code in detail yet but that's my understanding).

Both has the same functionality and depending on how frequent the config access is, having them durable may have a performance impact, but on the other hand from an observability point of view the per-call durability seems to be nicer, especially if a larger config map is associated with the worker - with the second approach we don't have any information about which particular keys the code is accessing and when.

This of course can also be seen as an advantage, because with the second approach adding/removing get-config calls is not causing any divergence while with the first approach it is.