Cross Compile and Cross Deploy and Cross Debug a target

Feature Request

So a very simple case version of what I am looking for is this, but understand I am really looking for the third step.

Very Basic First Starter Step
On your X64 Cross Compile a Linux C application for RASPBERRY PI (arm linux).

To debug, you must deploy the application to the remote machine
and Launch a remote debugger using something like GDBSERVER
and attach the GDB Debugger to that remote GDB Server.

A simple HELLO WORLD example would be great.

Here is an example:
https://deardevices.com/2019/04/18/how-to-crosscompile-raspi/

NOTE: Additional note: Any form of simulating or MOCKING the hardware is a non-starter. Please do not require QEMU, it must be 100% Optional. REASON: Because while the R-PI is some what supported there are many other targets that are NOT SUPPORTED by QEMU - so the user must be able to skip step 4 and go direct to step 5.

Another example is to use the ARM cpu target as a bare metal target on a PYNQ (or ZYNQ) board.

Second Step

Use the C++/TEST MATE or other example and run unit tests on that remote target (ie: VSCODE presents a BEEKER icon, click on the beaker and and you can select a unit test to run on the remote machine).

Third Step

The target is no longer a RASPBERRY PI - the target is actually a small embedded device. For example one of these:
https://learn.microsoft.com/en-us/azure-sphere/hardware/mt3620-reference-board-design

This third step is what I am really looking for - in my case it is a custom microcontroller board, similar to the MT3620 board but something else.

To make VSCODE unit test solution work, there are many many steps to get to this third stage that is is nearly impossible. I want to be proven wrong.

FOURTH STEP

As you will quickly learn, space and resources are limited in the embedded world. You will probably require 20 to 30 different build environments to build all of the different unit test configurations. Often just to make your code + unit test fit in the target you can only fit maybe 3 or 4 of your 20 to 30 total unit tests.

So you will learn that you need to be able to build (N+1) Variants for your various (N) UNIT TEST configurations, the +1 variant is for your final shippable product without any unit test framework present.

** ANOTHER VARIANT (simpler then embedded but has similarities) **

Run a LINUX machine on a HYPER-V virtual machine (or VMWARE machine) - you need to be able to SSH into he machine and run an application.

On your local Linux machine - compile an application and deploy the application to the remote Linux virtual machine and be able to debug the application.

Even better - be able to use the VSCODE unit test framework work to run unit tests (and debug) that remote application in unit test mode to.

** Final Variant - Build on Linux Ubuntu - Deploy to WSL **

Or the reverse, build on WSL for UBUNTU and deploy/run/test on a Linux machine - perhaps using SSH and/or a remote GDB Session.

No files, tests, or entry points are identified. Start by narrowing the broad cross-compile, remote deployment, debugging, and unit-testing request to one supported workflow, then define the target environment, integration points, and tests that would demonstrate completion.