Support changing a variables type in function workflow

Currently changing a variables type after core.function.generateMediumLevelIL will result in a partial update of the related variable analysis, this is because the activity core.function.generateMediumLevelIL encompasses too many independent steps, one of which is type propagation, the ideal fix to this is to split up the activity into smaller ones where we can actually place our activity before type propagation and other related steps.

https://github.com/user-attachments/assets/688e433b-1cff-49ec-aaae-c9459d4fdfd2

To reproduce:

1. Run this python script

ACTIVITY_NAME = "analysis.plugins.changeVar"
ACTIVITY_CONFIG = r'''{
    "name": "analysis.plugins.changeVar",
    "title" : "Change Variable",
    "description": "Blah",
    "eligibility": {
        "auto": { "default": true },
        "runOnce": false
    }
}'''
workflow = Workflow("core.function.metaAnalysis").clone()

def update_vars(analysis_context: AnalysisContext):
    func = analysis_context.function
    if func.start != 0x402d73:
        return
    mlil = analysis_context.mlil
    var = mlil[0].get_var_for_reg_after('eax')
    func_ty = func.view.parse_type_string("int32_t (* eax)(int32_t, int32_t)")[0]
    func.create_auto_var(var, func_ty, "test_var")
    var2 = func.get_variable_by_name('test_var')
    log_info(f"Activity `{ACTIVITY_NAME}` created {var2}")

workflow.register_activity(Activity(
    ACTIVITY_CONFIG,
    action=update_vars
))
workflow.insert_after("core.function.generateMediumLevelIL", ["analysis.plugins.changeVar"])
workflow.register()

2. Open hyperbolic depth recurses precisely and go to 0x402d8d
3. Observe that the type of eax in MLIL is correct at instr 0, but the type is not propagated to esi at instr 1

This is quite an unfortunate issue, we should look to address this soon as it is blocking important functionality regarding https://github.com/Vector35/binaryninja-api/issues/6404#issuecomment-2645934691

Marking this as an enhancement, but it could also just as easily be marked as a bug, I don't really see how this could be intended behavior.

Run the supplied Python workflow against core.function.generateMediumLevelIL and inspect the core.function.metaAnalysis and analysis.plugins.changeVar entry points. Trace the activity ordering around type propagation; done means changing the variable type causes the propagated type to appear on the later MLIL instruction at 0x402d8d.