feat: critical alerts by modules - 2

[AlexanderLukin]

Make several changes in the current critical alerts engine.

1. Now critical alerts are sent for each module individually.

2. Change the architecture of critical alert classes. Now these classes have moduleIndex field that allows them to detect for which module this critical alert should be triggered.

3. To optimize calculation complexity, raw data that are needed for critical alerts to calculate their state is now extracted from the critical alert instance methods to the higher level. Now these raw data are fetched in the CriticalAlerts service and are passed to the critical alert instances in constructors on creation time. Also, these data are filtered by a specific module and epoch to reduce the size of containers that critical alert instances should look over.

4. Introduce two new env variables CRITICAL_ALERTS_MIN_ACTIVE_VAL_COUNT and
   CRITICAL_ALERTS_MIN_AFFECTED_VAL_COUNT that allow users to define custom numbers for the count of active and affected validators for the particular module for which a critical alert should be triggered. Define priority rules for these values. Add support for the new affected validators mechanics to critical alerts. Describe new priority rules in README.

5. Now it is possible to set a share of active validators and a minimal threshold number for which a critical alert should be triggered in the new CRITICAL_ALERTS_MIN_ACTIVE_VAL_COUNT env variable. Previously these values were hard coded in the code and non-configurable.

6. Add a new nos_module_id label to all critical alerts. So now it is possible to route alerts depending on the module to different channels via Alertmanager.

7. Rules for sending critical alerts were slightly loosened. Previously alerts were sent when the number of affected validators was greater than the particular threshold. Now alerts are sent when the number of affected validators is greater or equal to the threshold.

8. Add information about the module to the alert summary.

9. Slightly change log info for critical alerts. Now logs display the critical alert name for every sent alert.

10. Calculate and store fetched module indexes in the Registry service and all dependent registry services (LidoSource, FileSource, KeysapiSource). This allows the CriticalAlerts service to fetch all available module indexes conveniently.

11. Fix a bug in the isValid module function of the FileSource service. This function considered key files with multiple modules as invalid. Now this function can correctly validate key files with multiple modules.

12. Update the custom_mainnet.yaml and custom_testnet.yaml templates to demonstrate how multiple modules can be defined in a file with keys.