Consider replacing panics with internal errors

[vytautas-astrauskas-sensmetry]

Sysand is supposed to be used as a library called from other languages via FFI. While unwinding via FFI boundary is possible, it is complicated and error prone. Therefore, we should consider whether to forbid panicking in the core and replace all points that could potentially panic with returning an internal error instead.

Related: #33

[victor-linroth-sensmetry]

No-Panic Rust seems like quite the large undertaking.

No-Panic Rust is not for the faint of heart. It requires a lot of careful, detailed work, and forces you to give up some niceties of Rust, like the standard library.

[andrius-puksta-sensmetry]

It's probably sufficient to not explicitly use unwrap(), panic!(), expect() ourselves in cases where it doesn't indicate a bug on our side.

[andrius-puksta-sensmetry]

Nice way of putting it:

[If] your library is the source of a panic, then one of the following should be true:

• Your library has a bug.
• Your library documents a precondition of a public API item that, when not met, causes a panic. Therefore, the user of your library has misused your library, and their code has a bug.

If your Rust application panics in response to any user input, then the following should be true: your application has a bug, whether it be in a library or in the primary application code.