GitHub WorkFlow pipeline split into separate "build" and "release" workflows

[LazaroOnline]

Currently the workflow pipelines are all in 1 file "autobuild_for_release.yml" which can only be run when a new release is published.

Goals:

• Separate the "build.yml" part from the "publish.yml" part in 2 separate workflows that shares the same "build" action.
• Enable running the "build" workflow manually from any branch to test it before merging new changes to "master".

Being able to run just the "build" workflow is important because
compiling locally is not the same as compiling in the workflow.
Most of us are using Windows and VisualStudio to compile,
while the workflow uses Ubuntu 22 Linux with mono.

The workflow can break for many reasons
appart from the mono-msbuild versus visualstudio-msbuild differences.
Sometimes in your local machine it compiles because
you have some required dependencies/SDK installed,
or local changes not commited.
The "build" workflow ensures it is all good.

Also whenever you modify something in the workflow itself,
it is easier to test separately.
Having a "build" only workflow is standard practice.
Some projects trigger the "build" on every commit to "master" to ensure the build is not broken.

I came across the current workflow limitation when adding the "checkout" with submodules for this other PR
it would also be used for migrating the csprojs to SDK style, and for the MacOS compatibility changes, or any significant change in the csprojs in general.

[LazaroOnline]

You can see an execution example in my Fork
which also includes this other PR that fixes the build that is currently broken in DGR's master branch.