Generator member predicate scoping is surprising

Generators (e.g. for generators, when generators) have their predicates scoped on the _outer_ object.

Often, this is a surprising behavior to our users. Consider this snippet:

```pkl
bar = true

foo {
bar = false
when (bar) {
qux = 3
}
}
```

This gives you a `qux = 3` property, which is surprising when you read this code.

The reason we can't actually resolve to names within the same object body is because generators get evaluated when the object gets created. OTOH, object members stay lazy until they are evaluated individually.

One possible fix here is to simply throw if the member predicate references names on `this`. So, the above code would become an error, rather than yielding a surprising result. This would be a breaking change.

Same applies for:
* when generator
* spread
* entry key
* member predicate

The issue names no implementation files, tests, or entry points. Start by tracing how generators, spreads, entry keys, and member predicates are evaluated and scoped, then determine which behavior should be retained for each listed case. Done requires an agreed resolution and coverage for the affected scoping rules.

Written by the indexing model from the issue text.