Update monolog/monolog requirement from ^2.9 to ^3.9

Dependency triage: Update monolog/monolog requirement from ^2.9 to ^3.9

Breaking changes (among others, see full [changelog](https://github.com/Seldaek/monolog/blob/main/CHANGELOG.md)):

**Post 3.0:**
- BC Warning: Fixed SendGridHandler to use the V3 API as V2 is now shut down, but this requires a new API key
- Deprecated Monolog\Test\TestCase in favor of Monolog\Test\MonologTestCase
- Deprecated Monolog\DateTimeImmutable in favor of Monolog\JsonSerializableDateTimeImmutable
- Deprecated FlowdockHandler & Formatter as the flowdock service was shutdown
- Deprecated CubeHandler and PHPConsoleHandler as both projects are abandoned and those should not be used anymore

**2.x -> 3.0:**
See [UPGRADE notes](https://github.com/Seldaek/monolog/blob/main/UPGRADE.md#300) for details on all breaking changes especially if you are extending/implementing Monolog classes/interfaces.

Noteworthy BC Breaks:

- The minimum supported PHP version is now 8.1.0.
- Log records have been converted from an array to a Monolog\LogRecord object with public (and mostly readonly) properties. e.g. instead of doing $record['context'] use $record->context. In formatters or handlers if you rather need an array to work with you can use $record->toArray() to get back a Monolog 1/2 style record array. This will contain the enum values instead of enum cases in the level and level_name keys to be more backwards compatible and use simpler data types.
- FormatterInterface, HandlerInterface, ProcessorInterface, etc. changed to contain LogRecord $record instead of array $record parameter types. If you want to support multiple Monolog versions this should be possible by type-hinting nothing, or array|LogRecord if you support PHP 8.0+. You can then code against the $record using Monolog 2 style as LogRecord implements ArrayAccess for BC. The interfaces do not require a LogRecord return type even where it would be applicable, but if you only support Monolog 3 in integration code I would recommend you use LogRecord return types wherever fitting to ensure forward compatibility as it may be added in Monolog 4.
- Log levels are now enums Monolog\Level and Monolog\LevelName
- Removed deprecated SwiftMailerHandler, migrate to SymfonyMailerHandler instead.
- ResettableInterface::reset() now requires a void return type.
- All properties have had types added, which may require you to do so as well if you extended a Monolog class and declared the same property.

New deprecations:

- Logger::DEBUG, Logger::ERROR, etc. are now deprecated in favor of the Monolog\Level enum. e.g. instead of Logger::WARNING use Level::Warning if you need to pass the enum case to Monolog or one of its handlers, or Level::Warning->value if you need the integer value equal to what Logger::WARNING was giving you.
- Logger::getLevelName() is now deprecated.

**Note: Dependabot checking for major version has been disabled through the attached PRs in the corresponding repos, please reopen PRs to re-enable Dependabot checking should you decide to move on with the update.**

**Note: monolog might be used on local server or AWS, do the corresponding tests (e.g. one OR the other OR both, as needed)**

## Acceptance criteria

- [ ] Test on Altis local server + Live testing environment on AWS
- [ ] Decision if we proceed with upgrade
- [ ] Do the Upgrade, or create a new ticket if (a lot) more work is required

## For Altis Team Use

### Ready for Work Checklist

Is this ticket ready to be worked on? See
[the Play Book Definition of Ready](https://playbook.hmn.md/play/product/definition-of-ready/)

- [x] Is the title clear?
- [x] Is the description clear and detailed enough?
- [x] Are acceptance criteria listed?
- [ ] Have any dependencies been identified? (Optional)
- [ ] Have any documentation/playbook changes been identified? (Optional)
- [x] Is an estimate or time box assigned?
- [x] Is a priority label assigned?
- [x] Is this ticket added to a milestone?
- [ ] Is this ticket added to an epic? (Optional)

### Completion Checklist

Is this ticket done? See
[the Play Book Definition of Done](https://playbook.hmn.md/play/product/definition-of-done-2/)

- [ ] Has the acceptance criteria been met?
- [ ] Is the documentation updated (including README)?
- [ ] Do any code/documentation changes meet project standards?
- [ ] Are automatic tests in place to verify the fix or new functionality?
- [ ] Or are manual tests documented (at least on this ticket)?
- [ ] Are any Playbook/Handbook pages updated?
- [ ] Has a new module release (patch/minor) been created/scheduled?
- [ ] Have the appropriate `backport` labels been added to the PR?
- [ ] Is there a roll-out (and roll-back) plan if required?