Hi @AT1234567, welcome to the forum 
mavproxy is a proxy service for connecting different MAVLink-based services and devices together into a MAVLink network, and it (or its equivalent service in BlueOS) is not something you should be modifying for autonomous operation - if anything you should just be using it to set up an endpoint which your code can then talk to.
Code on the Onboard Computer can be stored directly on the root filesystem, or within a BlueOS Extension. The latter is recommended because it makes your program more shareable and restorable, and has management infrastructure built into BlueOS, but is potentially a bit more work to set up when first starting out.
I’d recommend looking at the development documentation. Feel free to ask follow-up questions if there’s something that isn’t clear
I assume you mean the SD card, which is typically used for both file storage and the operating system running the device (e.g. Raspberry Pi OS). For BlueOS,
You can put files onto the Raspberry Pi via the BlueOS File Browser or Terminal (using red-pill), but you would need to do your own configuration to get those to run. BlueOS Extensions can be installed via the Extensions Manager.
At a high level, QGroundControl has a MAVLink telemetry connection with the vehicle, which is facilitated by a MAVLink Endpoint. If you write a Pymavlink program then it can connect to its own MAVLink endpoint to receive telemetry from the vehicle and send commands to it.
That depends what you’re trying to do, but if you want your program to have full control over the vehicle then you’ll likely need to disable QGC’s heartbeat messages.
SITL is a simulation program, and is unrelated to vehicle autonomy. It can however be used for testing autonomous functionalities in a virtual environment where there is no physical vehicle that could get damaged by poor operation.