Cleaning up Python module import infrastructure

[jcotela]

Now that #3586 is merged, the Python import infrastructure can be greatly simplified. This PR cleans up some of the darker things going on when an application is loaded. We have also taken the occasion to finally remove the old application_importer, which has been deprecated for 7 years now...

This PR is 100% backwards compatible but it also introduces a "more Pythonic" module import function _ImportApplicationAsModule. This one is optional but, if application developers choose to use it in their application's __init__ instead the current one, it does not add the application#s python_scripts folder to the python path. This means that python scripts would have to be imported relative to the application

import KratosMultiphysics
import KratosMultiphysics.FluidDynamicsApplication as kfd

# the next one is the big change 
import kfd.navier_stokes_solver_vmsmonolithic as solver
# alternatively
from kfd.navier_stokes_solver_vmsmonolithic import NavierStokesSolverMonolithic

This allows Kratos applications to work like native python submodules but, since it would break current scripts, it is not enabled by default.

[philbucher]

note that we ported the MappingApp right away to see how it is being used

[philbucher]

@KratosMultiphysics/technical-committee it would be nice to have this asap
Two rather large apps (IGA and CoSimulation) could then use it from the beginning and users would not have to update painfully at some point

[pooyan-dadvand]

@KratosMultiphysics/technical-committee approves the cleanup but let put on hold the optional part to maintain the backward compatibility

[philbucher]

@KratosMultiphysics/technical-committee just to clarify:
The change introduced here only removes the "old" way of adding stuff to the path for the next-gen python-interface of Kratos
Right now with the change I introduced in #3217 we have two ways of using python-modules: the pythonic way (e.g. import KratosMultiphysics.process_factory) or the "old"direct way (e.g. import process_factory)

The big apps already now support both ways (the later one for backwards compatibility)

Only new apps will use right away the new/correct/pythonic import system. There we don't need backwards-compatibility bcs there is no "old" way

From a user-point of view we already now use the "new" way for old and new apps
=> see e.g. the MainKratos.py in GiD:
FluidMainKratos
StructuralMainKratos