Update tinyuf2 0.35

[tyeth]

Description of Change

Updates the bootloader and tinyuf2 app bin files for the Adafruit boards.

Also fixes the csv name for the XIAO S3 tinyuf2 partition. It's got a partitions-8mb.csv but instead refers to a partitions-8mb-tinuf2.csv which is one of the tinyuf2 partition files that were renamed ages ago.
As the board appeared to be pointing to a non existent file, rather than point at the one in board folder this switches to the communal CSV (same content) and adds the 8MB No OTA partition scheme. Did the tinyuf2 bins for those xiao s3's too, did both after verifying same content between them.

Tests scenarios

Please describe on what Hardware and Software combinations you have tested this Pull Request and how.
Grabbed latest release zips from tinyuf2, as our CI has been, built with the bootloader and tinyuf2 files updated (plus boot_app0.bin), tested normal and tinyuf2 functionality.

Tested both tinyuf2 partitions for XIAO S3 in arduino ide blink example with updated boards.txt, then checked partition scheme correctly written, and tinyuf2 bootloader still works as expected (well half 😂 I was expecting double tap reset, but it's reset then tap boot button to enter tinyuf2 bootloader mode on XIAO S3).

[CLAassistant]

All committers have signed the CLA.

[github-actions]

Warnings

⚠️

Some issues found for the commit messages in this PR: the commit message "Merge branch 'master' into update-tinyuf2-0.35": probably contains Jira ticket reference (2-0). Please remove Jira tickets from commit messages. the commit message "Switch XIAO_ESP32S3 from tinyuf2 custom_partitions to shared partitions csvs": summary looks empty type/action looks empty the commit message "Update Adafruit boards to tinyuf2 0.35.0": summary looks empty type/action looks empty the commit message "Update XIAO S3 to tinyuf2 0.35.0, add no-OTA, use shared tinyuf2 partition csv": summary looks empty type/action looks empty the commit message "add new version of sparklemotion": summary looks empty type/action looks empty the commit message "fix clang complaints": summary looks empty type/action looks empty the commit message "fix": summary looks empty type/action looks empty the commit message "updated change as requested": summary looks empty type/action looks empty Please fix these commit messages - here are some basic tips: follow Conventional Commits style correct format of commit message should be: <type/action>(<scope/component>): <summary>, for example fix(esp32): Fixed startup timeout issue allowed types are: change,ci,docs,feat,fix,refactor,remove,revert,test sufficiently descriptive message summary should be between 10 to 72 characters and start with upper case letter avoid Jira references in commit messages (unavailable/irrelevant for our customers) TIP: Install pre-commit hooks and run this check when committing (uses the Conventional Precommit Linter).

👋 Hello tyeth, we appreciate your contribution to this project!

---

📘 Please review the project's Contributions Guide for key guidelines on code, documentation, testing, and more.

---

🖊️ Please also make sure you have read and signed the Contributor License Agreement for this project.

---

Click to see more instructions ...

This automated output is generated by the PR linter DangerJS, which checks if your Pull Request meets the project's requirements and helps you fix potential issues.

DangerJS is triggered with each push event to a Pull Request and modify the contents of this comment.

Please consider the following:
- Danger mainly focuses on the PR structure and formatting and can't understand the meaning behind your code or changes.
- Danger is not a substitute for human code reviews; it's still important to request a code review from your colleagues.
- Resolve all warnings (⚠️ ) before requesting a review from human reviewers - they will appreciate it.
- To manually retry these Danger checks, please navigate to the Actions tab and re-run last Danger workflow.

Review and merge process you can expect ...

We do welcome contributions in the form of bug reports, feature requests and pull requests.

1. An internal issue has been created for the PR, we assign it to the relevant engineer.
2. They review the PR and either approve it or ask you for changes or clarifications.
3. Once the GitHub PR is approved we do the final review, collect approvals from core owners and make sure all the automated tests are passing.
- At this point we may do some adjustments to the proposed change, or extend it by adding tests or documentation.
4. If the change is approved and passes the tests it is merged into the default branch.

Generated by 🚫 dangerJS against 8235fae

[tyeth]

Hey, if we want this partition scheme update in the next release plus in older version releases like 3.1.x and 3.2.x and 3.3.x then what's the correct way to go about it?

[tyeth]

DangerJS failure: Checks are being rate limited at GH, so CI needs kicking

[tyeth]

Drafting this to also add some verbiage updates for the partition schemes.
EDIT: Will do partition label updates in another PR if needed