Fix building library using Ninja

[fshstk]

This PR fixes two issues I ran into while trying to use libASPL for my own project. I have tested it and it should work exactly the same as before on setups where it was already working. Additionally, it fixes compatibility issues with the Ninja CMake generator, and a second minor issue I came across.

1. Making libASPL ninja-compatible

I use Ninja as my default build system, and I prefer using CMake's FetchContent for handling dependencies. Surprisingly, while libASPL works fine with the Makefiles generator, it breaks using Ninja. This is because the conditional logic for the gen commands will set BYPRODUCTS to an empty string if the files already exist, and Ninja does not allow multiple commands to have the same BYPRODUCTS.

(In fact, this led me down a rabbit hole about how CMake and Ninja interpret the meaning of BYPRODUCTS. Ninja will invoke the gen commands every time, even if byproducts exist. It will only compare the byproduct's modified timestamps before and after, and cancel re-building the byproduct's dependencies if the file doesn't change -- i.e. the gen command itself must decide if byproducts will be re-built or left as they are.)

Anyway I spent a lot of time playing around with the best approach to fixing this, and came up with a refactoring the generation commands into a custom function. Makefile builds still work the same way as before, but Ninja builds that were previously failing now work as well.

2. Providing a fallback when GIT_TAG doesn't match the version-string regex.

When testing out the fix above in my project, I pulled in my fork using FetchContent, e.g. like this:

include(FetchContent)
FetchContent_Declare(ASPL
  GIT_REPOSITORY https://github.com/fshstk/libASPL.git
  GIT_TAG        fix-ninja-builds)
FetchContent_MakeAvailable(ASPL)

add_library(myLib MODULE)
target_link_libraries(myLib PRIVATE libASPL)

However, libASPL applies a regex to GIT_TAG and expects it to be of the form v?([0-9.]+). Branch names like above result in an empty string, which leads to errors because CMake can't "see" empty strings unless they're in quotation marks. I added my fix for this to the PR as well.

[sizephyr]

Perhaps it would be better to fix the resource build process for releases? For example, add a version constant during build to this CMake file, or, as was done in one of my projects, generate a version file with a simple string containing the required project version? A zero version isn't the best idea, in my opinion.