Handling outlining in handle_promote

[ltratt]

In trace_builder::handle_promote we have this:

    fn handle_promote(
        &mut self,
        bid: &aot_ir::BBlockId,
        aot_inst_idx: usize,
        val: &aot_ir::Operand,
        safepoint: &'static aot_ir::DeoptSafepoint,
        tyidx: &aot_ir::TyIdx,
        nextinst: &'static aot_ir::Inst,
    ) -> Result<(), CompilationError> {
        match nextinst {
            aot_ir::Inst::Br { succ } => {
                // We can only stop outlining when we see the succesor block and we are not in
                // the middle of recursion.
                let succbid = BBlockId::new(bid.funcidx(), *succ);
                self.outline_target_blk = Some(succbid);
                self.recursion_count = 0;
            }
            aot_ir::Inst::CondBr { .. } => {
                // Currently, the successor of a call is always an unconditional branch due to
                // the block spitting pass. However, there's a FIXME in that pass which could
                // lead to conditional branches showing up here. Leave a todo here so we know
                // when this happens.
                todo!()
            }
            _ => panic!(),
        }

Says @jacob-hughes:

it's because Promote is secretly a call which has been turned into an opcode, and the hwtracer has returned to the successor block from the call, so we have to update our view of the world to reflect that

I then asked:

how do we know recursion_count = 0 is safe? what happens if e.g. a promote call is embedded in a callback?

Says @ptersilie:

we don't process any blocks during outlining. but i will need to check if the recursion count is needed here

EDIT: We should at least add some comments to the beginning of handle_promote to explain what the chunk of code above is doing. And, possibly, also to recursion_count = 0, because it is slightly surprising.