Feature request: add a dart_tools command line argument to support passing safe DartVM flags for debug and profile builds only.

Proposed name: --dart-flags
This is a development time only feature similar in intent to the --js-flags feature provided by Chrome. For example, in Chrome you can write
chrome.exe --js-flags="--trace-opt --trace-deopt --trace-bailout"
to launch chrome with custom JavaScript VM flags.

There is already a dart-flags flag in the flutter engine but it is not exposed by flutter_tools so it is impossible to run an app with the flag on without either editing the engine or editing the code for each of the platforms an app supports (e.g. IOS, Android, etc).
https://github.com/flutter/engine/blob/1c9457cedc51eb2f109a4a30da57b2daae0c1fd3/shell/common/switches.cc#L265
Before exposing --dart-flags further we should make this code not execute at all in release mode to avoid future bugs. A couple lines bellow in this file there is code to ignore some of the functionality outside of release mode.

A curated set of VM flags are exposed through flutter_tools but the list is incomplete and flags have to be added in a large # of places so it is impractical to add flags just for one off experiments such as changing the stack trace depth used for the sampling cpu profiler.
Example showing how many locations must be modified to flow through the VM flag start-paused:
https://github.com/flutter/engine/search?q=start-paused&unscoped_q=start-paused
https://github.com/flutter/flutter/search?q=start-paused&unscoped_q=start-paused
https://github.com/flutter/flutter/search?q=start-paused&unscoped_q=startPaused

It would be a good idea to provide a warning on app startup if custom Dart-VM flags are passed in to ensure this is used for one-off experiments rather than for typical user work flows. This is similar to how chrome will warn you if you are running with with non-standard flags.

Considerations:
We should ensure the flags are only passed in in debug and profile builds and never release builds. This is best done by ignoring the command line arguments completely in release builds. It would also be safest if the flags cannot be set by arguments to an android intents and similar even in a debug build so there are not any surprises on when the flags are set.

One option for added safety is to have a curated list of Dart VM flags in the DartVM adding a Dart_SetSafeVMFlags method similar to the existing Dart_SetVMFlags. This would further ensure users do not turn on VM flags that are not recommended for users outside the VM team.