[web_generator] Improve debugging of bin scripts with better stack traces

[nikeokoronkwo]

The stack traces produced by JS code are usually difficult to map/trace to Dart, and since we plan on maybe making this accessible to users as a public package (see #475), we shouldn't place this burden on users, and instead we should make it possible for easy debugging of this library.

We can use some of the JS types (error.stack if available else use Error.captureStackTrace() to add the trace) to get the stack trace in JS, parse the trace (either ourselves, or there is a popular stack-trace library we can use), and then use the source_map_stack_trace package to take the trace and the JS source map to produce a Dart-compatible source trace.

Although stack traces are not yet standardized in JS, they are widely implemented, and that includes V8 (node).

Although these stack traces are more helpful, they are not perfect and accurate, and while I'll try to improve the traces presented as best as possible, until they show a completely accurate representation of the code, we should add a --raw-traces (for lack of better name; name is tentative) flag to allow users to print the raw trace when reporting issues or bugs (or if we/they want to try to debug), which falls back to this normal trace.

@srujzs Wanted to know if this is something that would make sense before working on it.

[srujzs]

This is specifically for better stack traces (e.g. in translator.dart, transformer.dart) when the generator fails, right? If so, please! The development cycle is bogged down by JS stack traces and trying to figure out where and how something failed. Adding an option for --raw-stack-traces makes sense too.