Support `environment` parameter for `Isolate.spawnUri` about sdk

[a-siva]

@lrhn we seem to have some ambiguity between the way String.fromEnvironment is documented and implemented.
The documentation seems to indicate that the constructor is only guaranteed to work when invoked as const and may work on some platforms that have access to compiler options. However the non const invocations of it seems to work in an AOT environment too, The following program:

void main() {
  print('Foo: ${String.fromEnvironment('foo')}');
  print('Bar: ${const String.fromEnvironment('bar')}');
}
dart run -Dfoo='foo' -Dbar='bar' test.dart results in:
Foo: foo
Bar: bar

If we compile this to an AOT snapshot with no defines provided (dart compile aot-snapshot test.dart) and invoke dartaotruntime with the same defines as the JIT run (dartaotruntime -Dfoo='foo' -Dbar='bar' test.aot), we see the following:

Foo: foo
Bar:

Is the documentation correct or the implementation in the VM.

The reason this comes up here is because this issue has been filed to implement support for environment variables in spawnUri and if String.fromEnviroment is supposed to work only for the const constructor than this support becomes meaningless for the AOT case and it should probably also not do it in the JIT case in order to keep the behavior consistent between AOT and JIT.

[lrhn]

Seems like the VM implementation used whatever is available at the time of execution of the constructor.

The const invocation uses what was provided when the AoT program was compiled, the ringtone uses what was provided to it for the non-const invocation.

If we consider non-const invocation as unspecified behavior, then it cannot be wrong.
I'd still suggest to make the dartaotruntime ignore any -D flags, and treat the compilation environment as empty at runtime. That way nobody can start depending on it.

(I'd even make JIT code treat non-const invocations as running on an empty environment for consistency, but it's less important since it'll show as a single consistent environment. The example here could probably show different values for the same key, depending on whether it's const or not.)

[lrhn]

About spawnUri, I don't really understand how it works if not JIT-compiled. If it can target an AoT compiled program too, then I also wouldn't let that program see any compilation environment values.

For JIT spawnUri, compiler options could make sense, but I'd also be perfectly happy just using the same options as the running isolate. The use-case for changing compiler flags for an isolate seems likely to be testing, and JIT-only. Maybe it could be an option in dart:developer, so it's not used in production.

[bkonyi]

Is there any reason we wouldn't want to support runtime environment variables and just document the behavior? If this only worked for one of the runtimes, I'd agree it's worth making the behavior consistent. However, both native runtime modes support this behavior in what I'd consider an unsurprising way (the const constructor results in a compile time constant and the non-const constructor performs a lookup at runtime). Given the implementation can be done completely within the VM without explicit configuration by the embedder, I think it's safe to document this behavior as a feature.

If we're dead set against doing this, there really should be a way to prevent the non-const constructors from being invoked, either through a compile time error or throwing an exception.