Add eq validator

[RHammond2]

Summary

This PR adds the eq validator, which raises a ValueError when any value other than the expected value is passed.

There are two possible alternatives to having an eq validator, but it would be nice to have a direct means to effectively freeze the value of an attribute without the freezing the whole class for the few niche use cases I've run across.

# option 1
attrs.field(validator=attrs.validators.in_([2022]))

# option 2, as of 26.2
attrs.field(validator=attrs.validators.not_(attrs.validators.ne(2022))

Given the recent addition of validators.ne it felt right to add validators.eq to be used as follows.

attrs.field(validator=attrs.validators.eq(2022))

Pull Request Checklist

• I acknowledge this project's AI policy.
• This pull request is not from my main branch.
  • Consider granting push permissions to the PR branch, so maintainers can fix minor issues themselves without pestering you.
• There's tests for all new and changed code.
• Changes or additions to public APIs are reflected in our type stubs (files ending in .pyi).
  • ...and used in the stub test file typing_tests/baseline.py or, if necessary, typing_tests/mypy.py.
  • If they've been added to attr/__init__.pyi, they've also been re-imported in attrs/__init__.pyi.
• The documentation has been updated.
  • New functions/classes have to be added to docs/api.rst by hand.
  • Changes to the signatures of @attr.s() and @attrs.define() have to be added by hand too.
  • Changed/added classes/methods/functions have appropriate versionadded, versionchanged, or deprecated directives.
    The next version is the second number in the current release + 1.
    The first number represents the current year.
    So if the current version on PyPI is 26.2.0, the next version is gonna be 26.3.0.
    If the next version is the first in the new year, it'll be 27.1.0.
  • Documentation in .rst and .md files is written using semantic newlines.
• Changes have news fragments in changelog.d.

[hynek]

Thanks but eq is already covered by attrs.validators.in_()

[hynek]

sorry for being glib, I just noticed you mentioned in_, however you didn't really say anything against it, except, that you wouldn't have to type square brackets I guess?

[RHammond2]

The proposed addition of eq was so that the options for in_ couldn't be expanded, effectively freezing the value. It's not a common use case, I've come across, so I'm not too worried about using in_.

[hynek]

Internally it’s transformed into a tuple so that shouldn’t be an issue!