feat?(riscv): force inline (some) isr callees

This change gets a fair bit less clear; removing `#[ram]` from
`handle_interrupt` does indeed change the resulting binary (because it's
implicitly removing `#[inline(never)]`, but `get_core` is so small a
function LLVM will always inline it at all the optimization levels I've
tried, whether it's marked `#[inline]` or not.

So rather than a specific solution to an actual problem, this patch is
more of an example and a warning for what's to come: lacking a precise
mechanism to trace and identify properties of all callees along a
particular path, everything from here on out is highly dependent on
relatively distant effects: in attempting to assert whether "the trap
handling flow is entirely located in SRAM" we necessarily have to
qualify the answer with "given these optimization settings" (and, soon,
much worse).

If correcteness here is "not touching flash," then, in the usual
language of Rust, we're about to leave attempts at demonstrating
soundness behind. Instead, we now shift our focus to showing safety
under a particular set of (somewhat fragile) circumstances.

esp-hal-common/src/interrupt/riscv.rs

@@ -268,7 +268,7 @@ mod vectored {
         }
     }
 
-    #[ram]
+    #[inline(always)]
     unsafe fn handle_interrupt(interrupt: Interrupt, save_frame: &mut TrapFrame) {
         extern "C" {
             // defined in each hal

esp-hal-common/src/lib.rs

@@ -169,6 +169,7 @@ pub enum Cpu {
     AppCpu,
 }
 
+#[inline(always)]
 pub fn get_core() -> Cpu {
     #[cfg(all(xtensa, multi_core))]
     match ((xtensa_lx::get_processor_id() >> 13) & 1) != 0 {