Improve feedback to user when call parameter resolution is failing due to the stack being unresolved

[comex]

Version and Platform (required):

• Binary Ninja Version: 3.5.4307-dev (390387c6)
• OS: macOS
• OS Version: 13.3 (22E252)
• CPU Architecture: arm64

The binary being reverse engineered is also arm64.

Bug Description:

I used Override Call Type on a blr instruction, specifying a function type with 10 arguments. Yet the HLIL view only shows 8 arguments.

Steps To Reproduce:

1. Open this ELF and make a function at address 0.
2. Set the blr at 0xe8 to have this type with 10 arguments:

   int64_t calltarget(int64_t arg1, int64_t arg2, int64_t* arg3, int64_t* arg4, int32_t* arg5, int32_t arg6, int64_t* arg7, int32_t arg8, int32_t* arg9, int32_t* arg10)

3. Note that the decompiled call shows only 8 arguments:

   int64_t x0_4 = x8_3(arg1, arg3, arg5, x7, arg8, 1, &var_a0, 2)

The extra arguments are stored to the stack at 0xc8, but this is not being made part of the call for some reason.

[plafosse]

So the root cause of this is that the stack becomes undetermined because of an earlier call and the call type override your setting has stack variables and thus we don't know how to recover them properly. We should be doing a much better job of letting you know that you're kind of operating in a bad state.