[rasterio] Accept int EPSG codes and any to_wkt provider in CRSInput

[thomas-maschler]

Closes #16136

CRS.from_user_input normalizes every CRSInput value, and it accepts two forms the alias didn't cover: any object with a to_wkt method, checked before any concrete type, which is what makes pyproj.CRS work; and a bare int, read as an EPSG code via CRS.from_epsg.

The reported false positives (transform_bounds, reproject, MemoryFile.open with a pyproj.CRS) come from the first. I modelled it as a _SupportsToWkt Protocol rather than adding pyproj.CRS to the union, matching how _SupportsGeoInterface already handles shapely and geopandas geometries:

• rasterio doesn't depend on pyproj, so it isn't eligible as a stub dependency
• the runtime contract is structural, so naming one class would exclude every other CRS wrapper exposing to_wkt
• rasterio.crs.CRS and pyproj.CRS compare equal but hash differently, so they're better kept as distinct types
  Every current CRSInput call site normalizes through from_user_input (including _can_create_osr, the gcps setter, and calculate_default_transform), so widening with int is safe throughout. _transform_bounds and friends keep their CRS annotation, since those Cython signatures are statically typed and do reject anything else.

Added @tests/test_cases/check_crs_input.py covering the accepted forms and confirming an object without to_wkt is still rejected.

[github-actions]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

[jack-volantautonomy]

Great turnaround @thomas-maschler. This does just the job and does allow a pyproj.CRS to be supplied in our code. Happy with the change on my side.

[jack-volantautonomy]

@srittau How can we get this approved and merged?