AP_Scripting: allow expansion of memory for scripting at runtime

[tridge]

This makes it possible to expand the MultiHeap used by scripting at runtime. This means if the user underestimates the right value for SCR_HEAP_SIZE and they have free memory (which they usually do on a H7) then it will allocate more memory with a warning Note that:

• it will only expand the heaps if armed. If disarmed the user must fix their SCR_HEAP_SIZE
• expanding can be disabled with a SCR_DEBUG_OPTS option

This PR also cleans up the handling of scripting debug options

The motivation for this PR is there is really no way to predict in advance how much memory a set of scripts will need, so users may under-estimate and the scripts fail at a critical time

This PR also fixes an issue where realloc may fail if there is no room in the current sub-heap. We now always alloc/copy/ree. ChibiOS was doing this within a heap already, so this doesn't cost any more, but means it fixes a path for script failure

This was test flown on a Pixhawk6X

[IamPete1]

My only real concern is that the user won't notice. I think we should call the error handler in scripting so it will make a fuss and print the warning lots and will trigger a pre-arm. If we do that I think its fine to allow it to run when disarmed too. Currently just running out of memory only tells you that there is not enough, I think this method would be able to tell how much is needed. Ideally the users gets this error then puts the value into the heap size param and then never sees it again.

[tridge]

I think we should call the error handler in scripting so it will make a fuss and print the warning lots and will trigger a pre-arm

that would make their script fail, which loses the main reason for this PR which is to handle cases where a less common path in a script (eg. a failsafe handling) takes you over your memory limit and a critical script fails we could make it an InternalError, but I suspect @peterbarker would object as it is really not an internal error

[IamPete1]

that would make their script fail, which loses the main reason for this PR which is to handle cases where a less common path in a script (eg. a failsafe handling) takes you over your memory limit and a critical script fails

Sorry, bad wording, I didn't mean you actually error out, just call the set_and_print_new_error_message method. That is what will reprint the error a lot and cause a pre-arm. Ideally with a message something like "need SCR_HEAP_SIZE > x"

[timtuxworth]

When this says "makes it possible", what does that mean? From the dev call discussion it sounded like the RAM will be automatically allocated if needed when armed, which actually makes sense, but that's a bit more proactive than "makes it possible". Could you make it a bit clearer what's actually happening?