Expose mappings of requirements, provides and modules to modules

[hikinggrass]

This exposes functionality introduced in EVerest/everest-framework#206 to the modules

This needs EVerest/everest-cmake#14 because ev-cli is installed during configure from now on

[andistorm]

Would be nice to be able to "build" everest-utils without everest-core, this is currently not possible since the python executable isn't set by everest-utils

Options

1. Similiar to everest-core

option(${PROJECT_NAME}_USE_PYTHON_VENV "Use python venv" ON)
set(${PROJECT_NAME}_PYTHON_VENV_PATH "${CMAKE_BINARY_DIR}/venv" CACHE PATH "Path to python venv")

ev_setup_python_executable(
    USE_PYTHON_VENV ${${PROJECT_NAME}_USE_PYTHON_VENV}
    PYTHON_VENV_PATH ${${PROJECT_NAME}_PYTHON_VENV_PATH}
)

2. Error if Python3_Executable not set

if(NOT Python3_Executeable)
    message(FATAL_ERROR "Python3_Executeable not set")
endif()

3. Set Python3_Executable only if not already set

if(NOT Python3_Executeable)
    find_package(Python3 REQUIRED COMPONENTS Interpreter Development)
endif()

Option 1 is probably harder to use since you have to worry about more cmake variables when building everest-core, Option 2 doesn't allow building isolated, but gives a suitable error message
Option 3 doesn't allow to use "automatic" venv when building isolated

[mhei]

I'm just wondering whether this version shouldn't be in sync with the repo tags?

[hikinggrass]

Since it's a bit of an API change for modules I'd say I should probably at least bump it to 0.3.0, but that's a good point. The tagging of this repo doesn't really follow the versions of its content (ev-cli and everest-testing are bot at different versions at the moment).
This probably isn't going to be an issue for long, I'm preparing a PR at the moment that would move ev-cli into everest-core with the intention of keeping it a bit closer to the code it ultimately generates (everest-framework would also be a candidate for that)

[andistorm]

LGTM 🐧