Add debug objects

[laupow]

Story: https://app.shortcut.com/particle/story/118223/

This PR:

• aligns firmware binary output name with other Actions (artifact-path => firmware-path)
• adds new output that points to the target directory with debug assets from the compile (target-path)
• updates examples/docs to use the updated outputs

How to test

Run a local compile via env "INPUT_SOURCES-FOLDER=test/fixtures/single-file-firmware" env "INPUT_PARTICLE-PLATFORM-NAME=argon" env "INPUT_DEVICE-OS-VERSION=default" npm start (see dev docs)

• There should be a new target directory with the elf, lst, hex, and map files in the folder you ran the command
• you should see ::set-output name=target-path::target in the stdout/logs from the Action run

[keeramis]

I am able to verify this on my mac without issues.
A couple of observations that Matt and I talked about:

1. Since I had the target directory in my user app directory, the binaries were duplicated in the /workspace/target and /workspace/target/target directories. As discussed, this could be a side effect of local testing and can be ignored.
2. One recommendation is to use the app name instead of workspace.bin/.hex/etc (for example: workspace_myappname.bin. However, I am not sure if this is a useful recommendation in terms of the github actions and if it makes more sense to do hardcoded names on these files.

Thanks for the PR! It's great to see that we are one step closer to having (publicly) available .elf files that are needed for debugging.

[keeramis]

I am able to verify this on my mac without issues.
A couple of observations that Matt and I talked about:

1. Since I had the target directory in my user app directory, the binaries were duplicated in the /workspace/target and /workspace/target/target directories. As discussed, this could be a side effect of local testing and can be ignored.
2. One recommendation is to use the app name instead of workspace.bin/.hex/etc (for example: workspace_myappname.bin. However, I am not sure if this is a useful recommendation in terms of the github actions and if it makes more sense to do hardcoded names on these files.

Thanks for the PR! It's great to see that we are one step closer to having (publicly) available .elf files that are needed for debugging.