chore(ci): introduce daily pre-releases

Issue number: #4506

Summary

Test CI: https://github.com/heitorlessa/aws-lambda-powertools-python/actions/runs/9547633628 PR sample: https://github.com/heitorlessa/aws-lambda-powertools-python/pull/437/files

This PR introduces a new workflow to release alpha releases (a.k.a pre-releases) on a daily basis. This is due to last release having an undetected regression that a canary and tests with optional dependencies could've prevented.

With pre-releases, we have the following benefits:

Faster bugfix delivery for customers not wanting to wait the next release cycle. (note: bugs that affect most customers are delivered same day, that doesn't change it)
Test our release pipeline daily (except Layers)
Allows a future complex canary to test daily changes for timely feedback

Changes

Please provide a summary of what's being changed

[x] Verify RELEASE_VERSION is a pre-release version to avoid accidental releases / pollution
[x] Keep same steps and comments as much as possible from prod release
[x] Create manual dispatch trigger
[x] Create on schedule trigger
[x] Test a release manually
[x] Include provenance as part of release bump PR and src code
[x] Adjust build-changelog to run after pre-release so we can trace it (workflow+docs)
[x] Skip workflow if running on forks
[x] Include provenance in PR
[x] Create new trusted environment called pre-release to allow PyPi deployment
[x] Create GitHub Actions environment named pre-release
[x] Update install docs with tab on pre-releases to make it visible
[x] Adjust schedule to weekdays
[x] Update MAINTAINERS.md covering daily pre-release

Requirements matching

[x] Confirm whether .alpha over poetry default .a is a deal breaker (nope)
[x] Release every weekday early morning (on-call coverage, no impact to release day)
[x] Do not touch CHANGELOG (avoid spam, doesn't affect stable release on what's in it)
[x] PyPi only; do not release a new Lambda Layer (no alias yet, it'd impact versioning)
[x] Create PR to update pyproject.toml and shared/version.py (ensure deterministic for next release)
[x] Ensure it doesn't create a new release notes (avoid spam, provenance signing etc)
[x] Always autoincrement pre-release version (keep it simple over substantial checking for changes, dep/runtime devs etc)
[x] Run full quality check and test suite
[x] Do not release docs for each pre-release (develop covers it, avoid dropdown UX issue)
[x] Allow manual trigger a.k.a dispatch
[x] Release to PyPi prod, not PyPi test (test pypi maintenance and supply chain differences)
[x] Do not touch pending-release issues (no post-release prod tasks)

User experience

Please share what the user experience looks like before and after this change

Checklist

If your change doesn't seem to apply, please leave them unchecked.

[x] Meet tenets criteria
[x] I have performed a self-review of this change
[x] Changes have been tested
[x] Changes are documented
[x] PR title follows conventional commit semantics

Is this a breaking change?

**RFC issue number**: Checklist: * [ ] Migration process documented * [ ] Implement warnings (if it can live side by side)

Acknowledgment

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

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

aws-powertools / powertools-lambda-python