feat: Guild Message Search

[NeloBlivion]

Summary

Implements discord/discord-api-docs#8010
Requires MESSAGE_CONTENT intent and READ_MESSAGE_HISTORY in relevant channels
Pending:

• Docs
• Iterator parsing for threads and threadmembers
• Don't really know how I want to handle has and author_types, spec allows inversion with - so instead of an enum list i went with a True/False class (e.g. SearchHas(embed=True, link=True, image=False))
• Maybe move param parsing inside the iterator?
• Possibly change return from List[Message] to a SearchResults object

Information

• This PR fixes an issue.
• This PR adds something new (e.g. new method or parameters).
• This PR is a breaking change (e.g. methods or parameters removed/renamed).
• This PR is not a code change (e.g. documentation, README, typehinting,
  examples, ...).

Checklist

• I have searched the open pull requests for duplicates.
• If code changes were made then they have been tested.
  • I have updated the documentation to reflect the changes.
• If type: ignore comments were used, a comment is also left explaining why.
• I have updated the changelog to include these changes.
• AI Usage has been disclosed.
  • If AI has been used, I understand fully what the code does

[pycord-app]

Thanks for opening this pull request!
Please make sure you have read the Contributing Guidelines and Code of Conduct.

This pull request can be checked-out with:

git fetch origin pull/3160/head:pr-3160
git checkout pr-3160

This pull request can be installed with:

pip install git+https://github.com/Pycord-Development/pycord@refs/pull/3160/head

[NeloBlivion]

iterator seems to function reliably now

[Paillat-dev]

For the conditions we could have hijacked python dunders kinda like sqlalchemy but I feel like it would have been a little overkill.

[Paillat-dev]

😭

[NeloBlivion]

gave this a bit more thought, the intent is to have the same syntax as Intents or Permissions where you can easily pass True/False values, but we can't use the existing BaseFlags because they translate to completely different things on the API. I think the implementation itself is fine here, but as for naming how about something like ArrayFlags to convey a similar purpose? Or if we expect this to be limited to search, SearchFilters would be straightforward

[Paillat-dev]

Need to type this