Refactor FXIOS-14360 [Performance] Clean up autolayout issues

[thatswinnie]

📜 Tickets

Jira ticket
Github issue

💡 Description

Only adds the height and width constraints for toolbar button when it's a new button so we don't end up with multiple constraints. Any cached button already has the constraints.

📝 Checklist

• I filled in the ticket numbers and a description of my work
• I updated the PR name to follow our PR naming guidelines
• I ensured unit tests pass and wrote tests for new code
• If working on UI, I checked and implemented accessibility (Dynamic Text and VoiceOver)
• If adding telemetry, I read the data stewardship requirements and will request a data review
• If adding or modifying strings, I read the guidelines and will request a string review from l10n
• If needed, I updated documentation and added comments to complex code

[cyndichin]

code looks good, I didn't pull down to test. Let me know if you would like me to.

Just some thoughts around this:
It seems we have to add these cache to avoid re-triggering configuration or updating buttons that don't care about the action, but long term I wonder if we want to revisit this so that we are only updating the buttons that need to know about the actions and not necessarily all buttons. Maybe substates? In theory, then we may not need these additional cache logic? What do you think?

[mobiletest-ci-bot]

	Messages
📖	Project coverage: 38.48%

🧹 Tidy commit

Just 3 file(s) touched. Thanks for keeping it clean and review-friendly!

✅ Per-file coverage

All changed files meet the threshold of 35.0%.

ToolbarKit: Coverage: 63.96

File	Coverage
ToolbarButtonCaching.swift	100.0%	✅
BrowserNavigationToolbar.swift	92.91%	✅
BrowserAddressToolbar.swift	67.74%	✅

Generated by 🚫 Danger Swift against d9ecacb

[Cramsden]

This seems okay to me? It does not seem to resolve any of the constraint warnings or the amount of constraint warnings but it seems like it is probably good?