Add coregister=True to .xrs.rasterize to reproject GeoDataFrame geometries onto the caller grid

[brendancol]

Reason or Problem

The interpolation accessors .xrs.kde/idw/kriging/spline gained coregister=True in #3481. When the input is a GeoDataFrame, that flag reprojects its geometries from their own CRS into the caller raster's CRS before computing, so the surface lands on the caller grid even when the vector data is in a different projection.

.xrs.rasterize has no equivalent. Rasterizing a GeoDataFrame whose CRS differs from the caller raster either raises (the default check_crs=True), or, with check_crs=False, burns the geometries onto the grid without reprojecting them, so the burned pixels land at the wrong coordinates. Either way the user has to reproject the GeoDataFrame by hand before calling .xrs.rasterize. That is the manual step #3481 removed for interpolation.

Proposal

Add coregister=False to .xrs.rasterize on both accessor classes (DataArray and Dataset), mirroring the interpolation accessor. With coregister=True and a GeoDataFrame input, reproject the geometries into the caller raster's CRS via GeoDataFrame.to_crs before rasterizing. It needs a CRS on both sides (the GeoDataFrame's .crs and the caller's detected CRS) and raises a clear error otherwise. The default keeps current behavior, and the standalone rasterize() function stays unchanged. coregister is accessor-only, the same split #3481 used for interpolation.

Target call:

out = raster.xrs.rasterize(points_gdf, coregister=True)