Allow packet-level environment overlay

[jkomoros]

The best practice is to set a particular memory and store (and, in the future, prefix) that uses a distinctive prefix (e.g. komoroske.com) at the root of each seedGraph to make sure that all of the references within it use the same model/store/prefix.)

However, this quickly gets extremely repetitive in packets that contain lots of entrypoints, and for ones that are intermediate entrypoints, requires duplicative environment let-multi statements that were already done by seeds that called them.

We should add a property, environment, in a packet. It's an optional property, and should specify an EnvironmentData overlay. The starter environment for each seed in the packet will have that environment overlaid on whatever the previous environment was. It's as though each root-level seed is wrapped in a (hidden) let-multi with those properties.

What should the property be named? environment is a bit misleading because it implies it's the entire environment when really it's an overlay. let is a bit wrong because semantically it's a let-multi. vars is wrong because we use var to mean retrieve the environment. env is wrong because that's the only place in user-facing semantics that call it that.

When combined with #37, the convention will be to set a prefix in the packet-level environment every time.

A typical use case for this will be to set a namespace, but also set things like the model. The latter requires the former. Perhaps have the value be an object or an array of EnvironmentData. If it's an array then it should create the environment by overlaying each time. Actually, this might not be required, because namespace is late bound, so you can set it in the same block as another thing.

Originally tracked in #36.

• [x] Fix the sub-seed overlay problem documented below.
• [x] Update complex examples to not use top-level let but instead use environment.
• [ ] Fix the edge case for nested seeds getting the environment re-set for them and possibly overriding intermediate lets.

[jkomoros]

Wait, there's a problem: sub-seeds are passed an environment entirely derived by the caller, which means that seeds that expect a given environment to be set will not have that environment set when called as a sub-expression.

The fix is to make it so let/let-multi don't derive an entire environment but rather an overlay. That overlay is put over top of the base environment for each seed when grow() is called.

When this is fixed, update the TODO in README.

[jkomoros]

There's still one weird edge case: if you have nested seeds where inside the nested seed it changes the environment overlay with an additional let, it will be re-overriden by the seed's environment before it's executed. This seems like the kind of weird edge case that will be rare but when it bites will be REALLY confusing.

We could make it so private seeds don't get the environment overlay... but that's kind of a weird magical behavior?