refactor: use concepts more

[scarf005]

Checklist

Required

• I wrote the PR title in conventional commit format.
• I ran the code formatter.
• I linked any relevant issues using github keyword syntax so it can be closed automatically.
• I have committed my changes to new branch that isn't main so it won't cause conflict when updating main branch later.

Purpose of change

followup to #5514; concept is easier to understand than SNIFAE, let's use them more!

Describe the solution

check individual commits for details.

Describe alternatives you've considered

use less overloading trickery and just use different name for optional?

Testing

compiled in my machine (tm) but need to check if the concepts translation is correct because they're done 100% manually

Additional context

i'm dumdum and found this after i've done it manually: https://clang.llvm.org/extra/clang-tidy/checks/modernize/use-constraints.html

[OrenAudeles]

Windows build looks like it's failing to import vcpkg
Android build is choking in

generic_factory.h:805:8: error: expected concept name with optional arguments
      -> std::same_as<bool>;

[scarf005]

ahhhhhh outdated android libc++ version https://stackoverflow.com/questions/75942918/expected-concept-name-with-optional-arguments

[scarf005]

@OrenAudeles fixed in c3f5c00 (#5537)

[OrenAudeles]

nice, android build succeeded and since Windows build hasn't died from vcpkg it'll probably be okay. Once all of the builds finish it's probably okay to call it ready. TBH I'm not familiar enough with concepts nor requires to do a good job of reviewing this one.

[OrenAudeles]

Looks to be building fine, and only have the one question below because I'm not familiar with how JSON loading templatey stuff works other than "it just works"(tm).

[OrenAudeles]

Does the requires SupportsReader<...> here negate the requirement for the enable_if<is_constructible<...>> in the earlier default value optional implementation?

[scarf005]

err wait no i don't think so, lemme write a fix real quick

[scarf005]

done in a23cd22 (#5537), this one can be trusted because it's auto-migrated with clang-tidy. also #5540 because std::same_as is removed, preventing this error from happening

[OrenAudeles]

Looks good