Add initial type hinting support across the project (beta)

[BoggerByte]

This PR introduces comprehensive type annotations across the project. While not yet fully complete, the current implementation provides strong type support for the majority of the pipes and utilities, and can be considered a solid beta version.

The goal is to improve developer experience with better autocomplete, editor support, and static analysis via tools like MyPy, PyCharm, and VSCode.

✅ Summary of Type Hinting Coverage

Pipe	Support Level	Notes
take	✅ Full support	-
dedup	✅ Full support	-
tail	✅ Full support	-
uniq	⚠️ Almost full support	TypeGuard/TypeIs not yet supported
enumerate	✅ Full support	-
permutations	⚠️ Almost full support	Can't yet infer return type based on r param (e.g. r=2 -> Iterator[tuple[T, T]], r=3 -> Iterator[tuple[T, T, T]])
netcat	✅ Full support	-
traverse	⚠️ Almost full support	Works best with recursive Iterable[T | Iterable[T]] (with T before Iterable[T])
tee	✅ Full support	-
select / map	⚠️ Almost full support	TypeGuard/TypeIs not yet supported
takewhile	✅ Full support	-
skipwhile	✅ Full support	-
groupby	⚠️ Almost full support	Cannot infer return type of keyfunc
sort	⚠️ Almost full support	Same as above — keyfunc inference not yet handled
reverse	✅ Full support	-
transpose	🟡 Partial support	Only infers union of element types
chain	⚠️ Almost full support	Works with Iterable[Iterable[T]], not with unioned inner lists
chain_with	⚠️ Almost full support	Supports up to 5 args, then falls back to Any
islice	✅ Full support	-
izip	⚠️ Almost full support	Supports up to 5 args, then falls back to Any
t	✅ Full support	With proper overloads

✨ New Features

• Introduced a new cast pipe, which allows casting input to an explicitly specified output type.
  Still under discussion: whether it should include runtime type-checking or stay purely static.

⚠️ Known Issues

• mypy currently throws errors on chain_with and izip, although the type inference works as expected.
• Typing works well in PyCharm, but behavior in VSCode (with Microsoft's Python extension) is less consistent and needs further investigation.

🧪 Testing

• Type hints were manually tested in both PyCharm and VSCode.
• Plan to add automated tests specifically for type hint correctness in future commits.

❓ Questions

I'd appreciate input on whether we should default to Any or object in places where we can't infer precise types.

• Any tells the type checker “skip checking” - everything is allowed.
• object is the true top type - everything is compatible with it, but you can't do anything with it without a cast or check.

Using object encourages safer code but can feel more restrictive during prototyping. Let me know what you prefer for this codebase.

---

I'd love to hear your thoughts on this — especially around the new cast pipe and any ideas for improving support in VSCode. If you spot anything unclear, inconsistent, or just plain wrong, feel free to point it out. Feedback is super welcome, and I’m happy to iterate on this.

Thanks!