Improve buffer-accepting hashes and more

[hajimes]

This PR introduces the following improvements:

• The hash functions that accept the buffer protocol are now implemented with METH_FASTCALL, offering improved performance over legacy functions. This revision makes the function 50ns faster per execution on an Ubuntu instance in GitHub Actions, doubling the speed for inputs smaller than 100 bytes.
• Backward-incompatible: The seed argument is now strictly validated to ensure it falls within the range [0, 0xFFFFFFFF]. A ValueError is raised if the seed is out of range.
• The type of flag argumens has been changed from bool to Any.
• Add tox environments for benchmarking and plotting.

[hajimes]

Also,

• Deprecate the hash_from_buffer() function.
  Use mmh3_32_sintdigest() or mmh3_32_uintdigest() as alternatives.

[zadorozhko]

This PR introduces the following improvements:
* Backward-incompatible: The seed argument is now strictly validated to ensure it falls within the range [0, 0xFFFFFFFF]. A ValueError is raised if the seed is out of range.

This commit breaks MacOS Telegram library for encrypted sqlite db. Telegram uses hardcoded seed -137723950 for mmh3.hash

[hajimes]

Hi, thank you for your report! I'll change the seed range to [−2³¹, 2³² − 1] as soon as possible, with a clear specification that negative values will be interpreted as their bit-equivalent unsigned positive numbers.

[hajimes]

I concluded negative seeds should be handled on the user side (especially in the case of hard-coded ones), because limiting the value to be unsigned makes code faster and more clean, due to native functions Python/C API offer.

But I added a topic about the issue to the FAQ section of README to keep it user-friendly. Thank you so much for reporting the situation.