Improve scalability and separation of concerns

[claustres]

Now:

• we only use Weacast as an independent/external API
• services like vigicrues are built-in within the application

It would be useful for separation of concerns and scalability to allow:

• [x] the use of different DBs for different services (typically one local DB for app specific data like catalog and one global DB for shared data like vigicrues)
• [x] the use of an internal API to access shared meteo data from Weacast in Kano
• [x] to propose an internal API to access shared data like vigicrues, from Kano in others apps

Might be linked to https://github.com/kalisio/kdk/issues/7 although we don't necessarily want to build microservices for now.

[claustres]

See detailed proposed solution in https://docs.google.com/presentation/d/1GYv5Km1KOG1bVc2Cb8_OOvzcnFMc2W6C6MMa0YfRV0o/edit?usp=sharing.

[claustres]

Started prototyping a solution in the simpler Weacast environment: https://github.com/weacast/weacast/issues/42.

[claustres]

Using fathers-distributed does not work out-of-the-box on a swarm cluster, trying to use Redis now.

[claustres]

Tested fine with Redis.

[claustres]

Waiting for https://github.com/kalisio/kCore/issues/127 now to be able to address different DBs.

[claustres]

Waiting also for https://github.com/kalisio/feathers-distributed/issues/23 to avoid polluting e.g. Weacast with services coming from Kano.