ref(errors): Use enum for stacktrace order

[lobsterkatie]

Users can choose to display their stacktraces on the issue details page in reverse order, using the stacktrace_order user option. With a few caveats (see below), under the hood we store the option values as the strings "-1" (default), "1" (chronological order, with newest frame last), and "2" (same as default, reverse chronological order, with newest frame first).* In the front end we use numbers instead of strings, but with corresponding values.

Because the mapping is not obvious, this adds to the backend a StacktraceOrder enum (and a _SerializedStacktraceOrder enum to handle the conversion to numbers), and uses them rather than the corresponding strings/numbers. A similar change for the front end will happen in a follow-up PR.

Note: The description above is not strictly correct, for two reasons (each of which now has a corresponding TODO):

1. There are a small number of users which don't have any of these and instead have the empty string as their option value. This is treated the same as not having the option set at all, so it's not breaking anything, but we should nonetheless probably just clean those up.
2. "2" is not always the same as the default, or rather, the default behavior is not always to have the newest frame first. There is one place, (indirectly) in the Stacktrace interface's to_string method, where for Python events (and events with no platform, though practically speaking Relay normalization means there's always a platform) the default is the opposite, newest last. This doesn't match stacktrace ordering behavior anywhere else, so it might be worth investigating if we want to keep that special-casing in place. (It's also not immediately obvious where we (ultimately) use that method. Back when the special-casing was introduced (in late 2012), it was controlling the result of Stacktrace.to_html, but now we obviously let react create the HTML, and in our current front end there's no such exception for Python.)

[loewenheim]

I think this function could return a StacktraceOrder directly, there's no need to turn the enum into a boolean. Similarly, the newest_first parameter of get_stacktrace could then be a StacktraceOrder.

[lobsterkatie]

I think those are both valid points, but my preference would be to address them in a follow-up PR, so that this one can remain solely about switching to using the enum. (Happy to add a TODO about it here, though, since it would make sense to address your points alongside addressing the Python-special-casing question.)