bindings: decide how to handle panics at FFI boundaries

Currently, we make no effort to catch panics at FFI boundaries. This means that when compiled with panic=unwind, an uncaught panic will terminate the whole program when it hits the FFI boundary. This is a bit rude since we're embedded in someone else's code.

There's a policy question here: our policy on panics is that the public API has no undocumented panics, so panics that do occur are invariant violation bugs that are bad enough to be considered unrecoverable. So, perhaps termination on the FFI boundary is in fact the correct thing to do?

The two alternatives:

• Add catch_unwinds in all FFI entrypoints and convert them to a C-safe means of signaling errors (e.g. return a null pointer). This probably requires changing many of our APIs to be less ergonomic, since this means every single FFI call needs some way to signal an error that should never happen.
• @nrc suggests we could instead switch to the C-unwind ABI. I'm not familiar with it, but iiuc at a glance it converts rust panics into a form that can continue unwinding natively in the foreign universe (e.g. as a C++ exception). That would give callers in languages that can handle unwinds some control over panic handling, although again with our overall policy their options for recovery seem limited to trying to tear down tailscale-rs entirely and restart it, or abort themselves. @nrc want to say more?