Move annotation compatibility errors to validation phase

[sydney-runkle]

An attempt at addressing #9988

We apply annotations in 2 ways, in order of preference:

1. Directly to the type, like le to int
2. As an after validator wrapper that enforces a given constraint, like le around an arbitrary function after around an int. This ensures we respect annotation order.

We try to be pretty lax with #2, but this can cause problems if even a functional validator applying the given constraint isn't compatible with the inner type. Thus, I've added some support to our builtin functional validators to raise informative error messages when applying a constraint raises a TypeError.

Fix #9988

[cloudflare-workers-and-pages]

Deploying pydantic-docs with    Cloudflare Pages

Latest commit:	fd12aa4
Status:	✅  Deploy successful!
Preview URL:	https://34e38efc.pydantic-docs.pages.dev
Branch Preview URL:	https://strict-annotation-apps.pydantic-docs.pages.dev

View logs

[codspeed-hq]

CodSpeed Performance Report

Merging #9999 will not alter performance

_{Comparing strict-annotation-apps (fd12aa4) with main (f45033e)}

Summary

✅ 14 untouched benchmarks

[github-actions]

Coverage report

This PR does not seem to contain any modification to coverable code.

[adriangb]

Looks good!

[sydney-runkle]

We discussed one design pattern here - the create_constraint_validator ensures consistency in terms of error messages for lots of the constraints. It's a bit harder to understand than having more verbose + simple code.

That's a tradeoff I'd be willing to debate further in the future, if folks have strong opinions, but I think this is a good step forward for now.