Scripting errors/mistakes now consistently generate a runtime error
which have the behavior of unwinding the call stack all the way out of
the current event handler.
Before, such errors were not treated consistently and either aborted
the process entirely or emitted a message while continuing to execute
subsequent statements without well-defined behavior (possibly causing
a cascade of errors).
The previous behavior also would only unwind out of the current
function (if within a function body), not out the current event
handler, which is especially problematic for functions that return
a value: the caller is essentially left a mess with no way to deal
with it.
This also changes the behavior of the startup/initialization process
to abort if there's errors during bro_init() rather than continue one
to the main run loop. The `allow_init_errors` option may change this
new, default behavior.
Since values for local variables are referenced by offset within a Frame
(not by identifier name), and event/hook handler bodies share a common
Frame, the value offsets for local variables in different handlers may
overlap. This meant locals in a handler without an initialization may
actually end up referring to the value of a previous handler's local
that has the same Frame offset. When executing the body, that can
possibly result in a type-conflict error or give give unexpected
results instead of a "use of uninitialized value" error.
This patch makes it so uninitialized locals do always refer to a null
value before executing the body of a event/hook handler, so that using
them without assigning a value within the body will connsistently give
a "use of uninitialized value" error.
Addresses #932.
