Change how the bin/lib paths are set throughout CMakeLists

[ptheywood]

Change how the bin/lib paths are set throughout CMakeLists.

Includes overwriting per target output properties in some cases (gtest).

This should resovle #601, and shouldn't break standalone repos, but they would likely benefit from the minor change to their CMakes.

Todo

• Testing
  • Typical builds
  • Individual example main repo#
  • Windows
  • Standalone
    + Places into build/lib/ rather than _deps/flamegpu2-build/lib which may or may not be desirable? Change how binary/lib/dll directories are set FLAMEGPU2-model-template-cpp#3
  • Visualiser
  • CMake < 3.20 && >= 3.20 for something python related.
• Update all standalone repos (after this is merged)

[ptheywood]

On Windows this has led _pyflamegpu.pyd to be placed in /bin/Release/, as it's essentailly a .dll. This is probably not the correct location?

Each example is producing a .lib and .exp file which are placed in lib/Release I don't think these are something we are intentionally producing? I was only epxecting to see tinyxml2.lib, gtest.lib, pyflamegpu.lib (and maybe .exp) and `python/ in there.

From the output of cmake --build it does state that it's creating a library and an object:

 main.obj
     Creating library C:/Users/ptheywood/code/flamegpu/FLAMEGPU2/build/lib/Release/ensemble.lib and object C:/Users/ptheywood/code/flamegpu/FLAMEGPU2/build
  /lib/Release/ensemble.exp
  ensemble.vcxproj -> C:\Users\ptheywood\code\flamegpu\FLAMEGPU2\build\bin\Release\ensemble.exe
  tmpxft_000014ac_00000000-7_main.cudafe1.cpp

Current master produces the .lib still, but places it deeply in the build directory, so this is probably an unwanted change?

     Creating library C:/Users/ptheywood/code/flamegpu/FLAMEGPU2/build/examples/game_of_life/Release/game_of_life.lib and object C:/Users/ptheywood/code/fl
  amegpu/FLAMEGPU2/build/examples/game_of_life/Release/game_of_life.exp

On windows previsusly the values of CMAKE_ARCHIVE_OUTPUT_DIRECTORY and LIBRARY were unset, while binary was being manually set. Per target properties are inheritted from this manual setting.

Maybe we should be setting per target ourselves, depending on the type of target?