feat: Single Kernel Charm architecture and first handlers

[Gu1nness]

🏷 Type of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation Update
• Tooling and CI changes
• Dependencies upgrade or change

📝 Description

• Layout the repository structure (config, core, events, managers, state, utils, workload, lib)
• lib stores the charmhub libraries (better solution to find ?)
• Bring a (not-sufficient) first round of unit tests
• Already implemented : peer-relation, client relation, s3 relation, TLS relation
• Managers contains : config (handle configuration of each service), mongo for mongod related code, tls for TLS related code, backups for backup and S3 related code, mongodb_operator for mongodb operations and lifecycle
• Workload : One workload per service, with its configuration
• State : State of each relation + Peer relation + Model information
• utils : mongodb utils (user, connection, commands) + helpers
• config for all charm related constants
• core : abstract classes, secrets, charm config
• events: lifecycle for charm agnostic lifecycle events, backups for S3 related events, database for client related events, password_actions for get/set password, primary for get-primary, tls for TLS events.
• templates: the jinja template for logrotate (and if more templates to come)
• exceptions.py : All exceptions
• status: Very basic status manager, to be upgraded.

📑 Motivation and Context

This PR implements a huge amount of tickets and features, too long to be described here.
It bring the overall proposed structure, a lot of tooling, some basic integrations, some basic testing.

🧪 How Has This Been Tested?

• Not everything is fully tested yet.
• Tests are done with unit tests against a test charm stored in tests/unit/mongodb_test_charm
• Very basic manual testing of deployment

✅ Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.