bug: RustVM initiates builtins on a specific order that might not match the program's

[enitrat]

In runner.py, we have two different cases depenending on the VM used:

• PyVM:

        for builtin_runner in runner.builtin_runners.values():
            builtin_runner.initialize_segments(runner)


        # Handle builtins
        for builtin_arg in _builtins:
            builtin_runner = runner.builtin_runners.get(
                builtin_arg.replace("_ptr", "_builtin")
            )
            if builtin_runner is None:
                raise ValueError(f"Builtin runner {builtin_arg} not found")
            stack.extend(builtin_runner.initial_stack())
            add_output = "output" in builtin_arg
            if add_output:
                output_ptr = stack[-1]

• RustVM:

        # Must be done right after runner creation to make sure the execution base is 1
        # See https://github.com/lambdaclass/cairo-vm/issues/1908
        runner.initialize_segments()

This will cause an issue regarding the way we manage our builtins:

1. The PythonVM will initialize the builtins in the same order as the program's builtins, because we collect them in the same way
2. The RustVM has a specific preset of builtin orders:

        let builtin_ordered_list = vec![
            BuiltinName::output,
            BuiltinName::pedersen,
            BuiltinName::range_check,
            BuiltinName::ecdsa,
            BuiltinName::bitwise,
            BuiltinName::ec_op,
            BuiltinName::keccak,
            BuiltinName::poseidon,
            BuiltinName::range_check96,
            BuiltinName::add_mod,
            BuiltinName::mul_mod,
        ];

Thus, if a program has e.g. {bitwise_ptr, range_check_ptr}, then the RustVM will assign them segments 3 and 2, but the program will expect them to be in segments 2 and 3.