Expose hard_fault panicking behavior

[ia0]

This PR factors the hard-faulting logic out of the panic handler and makes it publicly available. The reasoning is that users may want to use that hard-faulting logic as the defmt::panic_handler to avoid double panic printing.

Alternative options:

1. Factor the hard-faulting logic out but don't expose it publicly. Instead, expose a feature that would define the hard-faulting logic as defmt::panic_handler.
2. Same as above, but reuse the print-defmt feature, essentially always setting the defmt::panic_handler.

Alternative (2) is probably the easiest for the user. The downside would be if for some reason the defmt::panic_handler should be set to something else instead. I don't see any examples, but that's a risk.

Alternative (1) is still easy (and that feature could be a default feature, or alternatively there could be a disabling feature) while keeping flexibility in case a user needs to define a custom defmt::panic_handler.

The current PR is the obvious non-breaking and flexible solution, but requires the user to define the defmt::panic_handler when needed.

[Urhengulas]

Thank you!

bors r+

[bors]

Build succeeded:

• ci

[ia0]

Thanks @Urhengulas ! Do you know when the next release of panic-probe would be expected? (I'm wondering if I should override my dependencies to defmt, defmt-rtt, and panic-probe with [patch.crates-io] or if I should wait for a release.)

[Urhengulas]

Thanks @Urhengulas ! Do you know when the next release of panic-probe would be expected? (I'm wondering if I should override my dependencies to defmt, defmt-rtt, and panic-probe with [patch.crates-io] or if I should wait for a release.)

We will make a release soon!

[ia0]

Thanks!

Then I'll wait and update google/wasefire#25 to use the new version instead of patching the dependencies.