[Story] - Review cores, kits public and private dependencies

[ladislas]

Description

While working on moving to mbed-ce, I've spent a lot of time reading, thinking about and reviewing the dependencies of libraries (cores + kits).

Currently, there are two main issues:

1. a lot of libraries (in the cmake sense) link against mbed-os and a lot of other cores and kits. The main impact is object size and link time. As we add more libraries and spikes, they can become quite long and pain in the neck of the developers

2. our public APIs often disclose implementation details which force us to link publicly against other libraries thus making everything depend on everything

An example is BatteryKit which depends on CoreEventQueue publicly where as it's an implementation detail. Using BatteryKit should not force the user to have access to CoreEventQueue

And a spike needing CoreEventQueue should not rely on the fact the it is provided by BatteryKit but link against it clearly.

A solution would be to not depend on CoreEventQueue but on an interface of event queue and use DI in the spikes to pass the dependencies, as we usually do.

Related epic/story:

• review the use of mbed-os - [Task] - Review CMake target link with mbed-os almost everywhere #1295
• review public APIs to make sure everything is needed
• BatteryKit + CoreEventQueue
• BehaviorKit + spike
• CoreLL --> not interface
• CoreGraphics + CoreLL --> move implementation to .cpp
• ReinforcerKit + MotionKit + ActivityKit
• FileSystemKit + lk_lcd + lk_fs --> create StorageKit
• LEDKit + spike lk_led_kit
• CoreEventQueue
• LogKit
• all kits
• SD + Fat --> StorageKit + FileManagerKit + public deps?