fix(logger): add xray_trace_id to every log

[dreamorosi]

Description of your changes

As reported by user @humanzz in #773 the Logger utility was not including the xray_trace_id key in logs. This field is listed in the documentation as a standard key that should appear in each log.

The user reporting the issue was helpful in detailing the fact that the _X_AMZN_TRACE_ID environment variable used to retrieve the value changes at every invocation while Logger was instead attempting to read this value when instantiated (see constructor -> setOptions -> setPowertoolLogData).

This PR changes this behaviour and appends the xray_trace_id key when the log entry is created and populated instead (createAndPopulateLogItem function). This behaviour is consistent with the implementation also used in the Python version of Powertools.

As additional notes:

• This was not caught in unit tests because the environment variable is set by packages/logger/tests/helpers/populateEnvironmentVariables.ts which is imported before tests are run. So when running the tests the xray_trace_id would always be present.
• This was not caught in the e2e/integration tests either because no assertion was made on the presence of this key in the logs (this PR adds a test case to check this).
• The documentation erroneously stated that this key should be set only when Active Tracing is enabled. This is not true as the _X_AMZN_TRACE_ID environment variable is always set in the Lambda execution environment, regardless of whether tracing is enabled or not. This means the key will always be present in each log. AWS Lambda Powertools for Python makes the same statement and I have tested the latest version available of the library on a Lambda function with Active Tracing disabled and the key is also always present in each log.

How to verify this change

• See unit test results in this PR
• See result of e2e tests here
• See example of CloudWatch logs generated after this change (below)

Related issues, RFCs

#773

PR status

Is this ready for review?: YES
Is it a breaking change?: NO

Checklist

• My changes meet the tenets criteria
• I have performed a self-review of my own code
• I have commented my code where necessary, particularly in areas that should be flagged with a TODO, or hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• The code coverage hasn't decreased
• I have added tests that prove my change is effective and works
• New and existing unit tests pass locally and in Github Actions
• Any dependent changes have been merged and published in downstream module
• The PR title follows the conventional commit semantics

Breaking change checklist

N/A

---

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

[dreamorosi]

See e2e test result here (passing): https://github.com/awslabs/aws-lambda-powertools-typescript/runs/6041778790?check_suite_focus=true