allow use of external memory as heap with TOOLCHAIN_GCC_ARM

[bmcdonnell-ionx]

This PR addresses #5638. It allows the user to optionally (with the right additional software) use external memory for all dynamic memory with TOOLCHAIN_GCC_ARM, by allowing the user to override the _sbrk() function defined in platform/mbed_retarget.cpp.

For example, when using the Embedded Artists' LPC4088 QuickStart Board with EALib's SDRAM module (cpp, h) and the Mbed online compiler (and Keil uVision offline IDE, I presume), dynamic memory uses the off-chip on-board 32 MB SDRAM. I assume there are other boards that can support this behavior too, but this is the one I know of for sure. This PR makes this behavior the same on TOOLCHAIN_GCC_ARM.

[mbed-ci]

User not whitelisted, CI not run.

[cmonr]

/morph build

[cmonr]

/morph build

[studavekar]

/morph build

[mbed-ci]

Build : SUCCESS

Build number : 1045
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5994/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build

[mbed-ci]

Exporter Build : SUCCESS

Build number : 726
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/5994/

[mbed-ci]

Test : SUCCESS

Build number : 853
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5994/853

[mbed-ci]

Exporter Build : FAILURE

Build number : 2361
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/5994/

[bmcdonnell-ionx]

I just edited a typo in the OP here, and for some reason the CI did whatever it just did above.

🤷

[cmonr]

@bmcdonnell-ionx Yeah, it's a known ghost in the machine that happens every once in a while, but considering how fast it fails and that it doesn't impact anything else in CI, it's a low priority fix.