Reduce User monkeypatching

[eemeli]

Built on top of #4196, actual diff here is here -- so will probably need a rebase before merging. Edit: Done.

---

Over time, we've ended up monkeypatching a plethora of functionality onto the base User object, via its add_to_class() method. While this does make the methods and properties available everywhere, they're also hard to discover and get no editor support.

This PR moves most of these utility functions into pontoon.base.badge_utils, pontoon/base/notification_utils, pontoon.base.user_utils. A few are left in to keep them available in templates, which would otherwise need to have their contexts include the utility-provied values. For the methods and properties left on User, a type-hinting-only subclass is provided for better editor support -- this also provides a place to define the model's foreign-key relationships.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 81.12798% with 87 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.72%. Comparing base (b0906cc) to head (cb91796).

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mathjazz]

Looks good.

Could we document which helpers intentionally remain monkeypatched on User, and why? The split is reasonable, but without a short comment, it’s hard to tell later whether a remaining add_to_class() method is intentional or just not migrated yet.