[Issue 19984] Support shared in foreach lambdas

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=19984

--- Comment #3 from Manu <turkeyman at gmail.com> ---
That's a pretty disappointing solution, because it leaves the massive un-safety
that I'm trying to address in place.
In your example you can use `_.s` from the capture, but you can also still
refer to `s`, which is the obvious thing to do, and it's a race waiting to be
typed.
It's unreasonable for the interior of the for loop to have not-shared
references to outer values.

Basically, I'm proposing that since the opApply implements the loop, and it
defines what is safe to do from inside the loop body, an effective way to
assert that function's specification of what is valid inner-loop code, is to
infer the function attributed from the opApply function onto the lambda that it
receives.

an `opApply(...) shared` method that inferred the `shared` attribute onto the
loop body lambda feels like a really appropriate way to achieve this outcome.
It might also be reasonable that some loop body may not write to outer scope,
and it could infer `const` the same way, etc.

--