getStackTrace does not properly handle errors thrown by "stop" #115

Currently, getStackTrace supplies a pruned (concise, with non-Dash related calls removed) or raw (everything) traceback when a Dash app is initialized with debug=TRUE.

This worked well for spontaneous errors, but did not properly handle user-defined stop conditions; the stack trace would not be displayed in the console or browser:

in debug mode, catching error as warning ...
warning: Execution error in stop: Winnipeg? from NULL
request: 127.0.0.1 - ID_127.0.0.1 [13/Aug/2019:10:34:57 -0400] "POST /_dash-update-component HTTP/1.1" 200 38 "http://127.0.0.1:8050/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1 Safari/605.1.15"

In addition, in one instance, the following JS console error would be sent up to the renderer and appear in the dev tools UI:

Addressing this issue could prove somewhat complicated, since stop calls are stored as symbol objects, and can't be treated directly as strings:

Error in sprintf(template, header, throwing_call, error_message, formattedStack) : 
  invalid type of argument[2]: 'symbol'

A workaround might be to deparse the object, which will return a string. A solution should be identified such that getStackTrace properly handles user-defined errors, just as it does for more spontaneous exceptions.