A few CMake quality of life suggestions

[andesyv]

Hello! I stumbled upon a few tiny annoyances while working with the toolkit and I thought I should contribute by making a pull request about it, in case my modifications might be useful for someone else. Mainly the modifications adds a few more checks / verifications in various places. For instance by checking if things like if the specified language is among the available ones in the config.json file or if the incorrect path to the devkit was given in the configuration.

But additionally it also separates the GenerateAddOnProject function into two separate "CMake-like" functions add_addon and target_addon_resources to allow for more customizability in the project setup. This allows for syntaxes like:

add_addon (AddOnTarget
  NAME ${AC_ADDON_NAME}
  DEV_KIT_DIR ${AC_API_DEVKIT_DIR}
  AC_VERSION ${AC_VERSION}
)

file (GLOB_RECURSE headers ${CMAKE_CURRENT_SOURCE_DIR}/MyHeaders/*.hpp)
file (GLOB_RECURSE sources ${CMAKE_CURRENT_SOURCE_DIR}/MySources/*.cpp)

target_sources (AddOnTarget PRIVATE
  ${headers}
  ${sources}
)

target_addon_resources (AddOnTarget
  RESOURCE_ROOT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/Resources
  SOURCES_ROOT_DIR ${sources}
  LANGUAGE_CODE ${AC_ADDON_LANGUAGE}
)

Compatibility with current usages of GenerateAddOnProject should be retained so current projects shouldn't be affected (I think).

[vhorvath-gs]

According to my understanding the tools here and the public add-on template are provided for the simplest use-case where a 3rd party developer wants next to no involvement with the build system and thus doing things "right" is not a priority (as evidenced by the use of GLOBs) as opposed to making things "just work". To this end, I don't see splitting the functions as a benefit at all.

For any real customization, one does not need any of the code provided here nor the add-on template. This is completely fine, since the support code provided is a really small amount, where the important parts can easily be copied.

What I see as a net positive in this PR are the check and verify functions that narrow the contract and provide guidance in case of false assumptions made by the supporting code. I would very much like to see those changes made into a separate PR and I would welcome those changes.

[andesyv]

Thanks for the review! I've reverted the changes relating to splitting up this function while keeping some of the safety checks as suggested.