Is your feature request related to a problem?

I've noticed that xarray does not support the lshift or rshift operators. While this is workable by using the numpy array the addition of the operators also seem somewhat trivial and reduces friction for numpy users adopting xarray.

Is the exclusion of these operators intentional or oversight or some other historic reason?

Describe the solution you'd like

Implement the operators if it makes sense.

Describe alternatives you've considered

No response

Additional context

I experimented with the potential edits here: https://github.com/abrammer/xarray/tree/feat/add_lshift_and_rshift_operators but don't want to open a PR without an initial discussion. I haven't delved into this area of xarray before so I probably missed something or did something wrong.

This seems a little too easy, but the PR just adds lshift and rshit to generate_ops.py and ops.py then generated the 2 stub files with generate_ops.py.

• [x] Closes #7727
• [x] Tests added for:
• xr.Variable
• DataArray
• dask
• groupby
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst
• There will be new << >> syntax for dataarrays and datasets.
• [x] New functions/methods are listed in api.rst
  • Existing basic math operators aren't really listed, that I can find.
  • Could add example code in the "Data arrays also implement many numpy.ndarray methods:" section of computation.rst ?

I'll wait for initial review before spending time on whats-new and api docs.

This enables bit shifting on arrays (when the type supports it).

```python import xarray as xr

x = xr.DataArray(5) print(x << 1)

<xarray.DataArray ()>

array(10)

x = xr.DataArray([0,1,2,3,4,5]) print(x << 1)

<xarray.DataArray (dim_0: 6)>

array([ 0, 2, 4, 6, 8, 10])

Dimensions without coordinates: dim_0

x = xr.DataArray([0,1,2,3,4,5]) print(x >> 1)

<xarray.DataArray (dim_0: 6)>

array([0, 0, 1, 1, 2, 2])

Dimensions without coordinates: dim_0

x = xr.DataArray([0,1,2,3,4,5.]) print(x >> 1) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/workspaces/xarray/xarray/core/_typed_ops.py", line 255, in rshift return self._binary_op(other, operator.rshift) File "/workspaces/xarray/xarray/core/dataarray.py", line 4566, in _binary_op f(self.variable, other_variable) File "/workspaces/xarray/xarray/core/_typed_ops.py", line 461, in rshift return self._binary_op(other, operator.rshift) File "/workspaces/xarray/xarray/core/variable.py", line 2662, in _binary_op f(self_data, other_data) if not reflexive else f(other_data, self_data) TypeError: ufunc 'right_shift' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule ''safe'' ```

• [x] Closes #2090
• [x] Tests added
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API
• [x] Add further examples to User Guide Docs

Building on #2144, I added dask support and returning the appropriate object type.

The two initial commits show alternate approach to handling cftime values. Either adding strftime to cftimeindex and accessing that way (commit 5de4db1) or just rolling the loop within the datetime accessor and not touching cftimeindex at all ( 51239c9). can revert commit 5de4db1 if its preferred to not touch cftimeindex for any reason.

Can clean up docstrings and minor formatting after some input on the implementation details.
Is there a vectorized or better method for the cftime values? List comprehension was the best I could come up with, borrowing from similar logic elsewhere in the code.