feat(logger): basic logger logic

[saragerion]

Issue #, if available:

Description of changes:

This is a PR containing the business logic for the logger, and it's part of this list:

• CURRENT: create logger logic with basic unit tests and examples
• TODO: Update test suite with missing unit tests and relevant test cases/scenario
• TODO: Create docs
• TODO: CI/CD pipeline for publishing

Usage

See readme file for examples.

Key features

All functionalities/features existing the other loggers are (or should be, unless I missed them) implemented and part of this PR.

The TypeScript logger differs from the others in these features:

1. Decorator functionality is not in this PR.
TypeScript currently only supports Decorators for Classes.
This means that to make decorators work folks need to change their code to make the Lambda handler a method of a class. This is not a common practice of how folks implement the handler logic for the Node.js runtime, as far as I know. Please feel free to add your perspective on this in the review.

2. Possibility to configure the logger settings (options) via constructor or custom configuration service
On top of the already existing configuration for the logger that can be done via environmental variables, developers can optionally bootstrap the logger settings by passing them in the constructor, or relying on a custom configuration service (that could extend the functionality of the existing one, or be of a different kind like AppConfig).

Options for the logger (log level, feature toggles on/off) are set dynamically by checking these "sources", in this specific order:
settings passed in Logger class constructor settings declared in custom configuration service settings declared in default environmental variables service.

3. BYOL: Bring Your Own Log (structure)
This powertool's logger by default prints logs having the same JSON schema as the other tools.
I extended this functionality to optionally allow developers to set their own log JSON schema, if they want to.
The reason behind this choice is that some developers, especially in big organizations, might need to comply with their company's standardized logging RFC and schema implemented company-wide for Lambda, containers, or code running on EC2. This is a necessity when logs are sent to a central logging SaaS vendor and the log key/values need to be indexed.
Another use case could be implementing a JSON schema compatible with the opentelemetry-specification standard.

4. Location field is missing
This is honestly a great feature the other tools have. But currently there is no easy or not-hacky way to get this information in Node.js/Typescript. The closest feature I found is this library here.
Shall we use it?

Checklist

• Meet tenets criteria
• Update tests (see PR description above)
• Update docs (see PR description above)
• PR title follows conventional commit semantics

Breaking change checklist

RFC issue #:

• Migration process documented
• Implement warnings (if it can live side by side)

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[heitorlessa]

This is so awesome to see 🤩🎉

Because it's a big PR, could you update the PR description or Logger.md with examples of usage?

That would be quicker as I'd focus on the UX first, and get acquainted with the project tooling and structure as I go along ;)

Thank you!!!