Split repository: core and petals

We will soon split the repository into two repositories: one that contains the core functionality and one where extensions of CLIMADA can be developed without interference with the essential parts. This would be "climada_petals". The idea is to have better control and higher standards on the core while there is the opportunity to explore and further develop its use and functionality range in a safe but non-prohibitive environment.

What goes where?

Basically core contains the essential modules and classes while petals hosts their specific implementations and extended functionalities. Some modules will eventually be present in both repositories, but with different scope.
These modules are designated to be moved to CLIMADA petals:

climada,engine.supplychain
climada.entity.exposures.black_marble
climada.entity.exposures.crop_production
climada.entity.exposures.gdp_asset
climada.entity.exposures.open_street_map
climada.entity.exposures.spam_agrar
climada.entity.impact_funcs.drought
climada.entity.impact_funcs.relative_cropield.py
climada.entity.impact_funcs.river_flood
climada.hazard.drought
climada.hazard.emulator
climada.hazard.emulator.const
climada.hazard.emulator.emulator
climada.hazard.emulator.geo
climada.hazard.emulator.random
climada.hazard.emulator.stats
climada.hazard.emulator.test
climada.hazard.emulator.test.test_emulator
climada.hazard.emulator.test.test_geo
climada.hazard.emulator.test.test_random
climada.hazard.emulator.test.test_stats
climada.hazard.landslide
climada.hazard.low_flow
climada.hazard.relative_cropyield.py
climada.hazard.river_flood
climada.hazard.tc_rainfield
climada.hazard.tc_surge_bathtub
climada.hazard.tc_tracks_forecast
climada.hazard.wildfire

Transition plan

1. Create a clone of climada_python: climada_petals
2. Rename the top source directory of climada_petals, climada, to climada_petals, all branches
3. Split sources in develop branch of both repositories
   1. Remove all modules from climada_python that are going to be petals
   2. Remove all modules from climada_petals that belong to the core
   3. Split all modules that will remain in both repositories without overlaps, if possible.
4. Merge changes of the two develop branches to main
5. Remove feature branches from both repositories if they have nothing left to merge, i.e., branches that clearly belong to either core or petals.
6. In both repositories, merge changes of the respective develop branch to all remaining branches.
7. Clean up repositories, remove non-source files from both repositories where they are not required anymore. This is not critical in terms of coordination, there shouldn't be any side effects on the feature branches, a simple merge without conflicts can be expected.

For steps 1 to 5 there will by a single responsible developer (Emanuel), for step 6 the contribution of all developers is requested. We will call for a development freeze starting from July 19 until 1 to 5 are done, hopefully by July 25. Afterwards we'll ask all owners of feature branches to make step 6 and adapt their branches to the changes of this transition. Once step 6 is done for a branch, developers can continue with the development in their branch, possibly in both repositories. Step 7 will then be done subsequently, in preparation for the release of September 1st.

Transition Plan Update

Steps 1-6 were done by end of July. Step 7 in more detail:

• check each data file in the data directory and climada_petals/climada_python, whether it is used in both repositories
  remove unnecessary files
• remove doc/guide files from climada_petals
• overhaul guide_installation.ipynb
• configure readthedocs properly for climada_petals (currently, as of August 25, the build is still failing)