ENG-5956 sqlcmd error handling improvements

Restructured try/catch blocks and a few throws especially in the area of exec parameter validation, mainly to allow more consistent options for stopping immediately on error or soldiering on, and returning a proper exit code on actual errors. But also a little bit just to eliminate redundant code.

Did NOT address the clumsy code sharing between interactive and batch modes (source of batch mode bugs and lots of unwanted complexity) 
or the lack of code sharing between batch mode and the almost-yet-should-be-more identical "script file read" mode.

Did not address needless complexity and compute costs in the LIST commands, in procedure identification, and in literal string handling.
"Need" is a strong word. Since we haven't historically supported bool/Boolean parameters to stored procs, the system procs were defined to use 0/1 instead, so we NEED to support that for consistency. 
Given the underlying meaning of 0/1 in this context, true/false seems like a reasonable sqlcmd nicety, though I'm not 100% sure it's worth the effort, and case insensitive would be nice. "yes" is pushing things. and allowing garbage to mean 0 is just wrong.
What's VERY wrong is the combined effect of 'TRUE' being garbage and garbage being 0 so that 'TRUE' means the same as 'false'.

I don't think it'd be that much work to add support for Bool/boolean to stored procs (though NOT to SQL '?' parameters). Supporting implicit conversion from 1/0 or the strings "true"/"false" in the ProcedureRunner parameter processing would even allow us to do this backward compatibly.