Update the time shift Ruptures function with the new logic that was tested/validated at PVRW 2023

[kperrynrel]

This update makes the changes to the original function so it now matches the finalized logic that I used for validation in the PVRW 2023 poster (https://www.nrel.gov/docs/fy23osti/85699.pdf). Most notably, we use binary segmentation instead of Pelt here, which results in a massive speedup while still being performant.

• Added tests to cover all new or modified code.
• Clearly documented all new API functions with PEP257 and numpydoc compliant docstrings.
• Added new API functions to docs/api.rst.
• Non-API functions clearly documented with docstrings or comments as necessary.
• Adds description and name entries in the appropriate "what's new" file
  in docs/whatsnew
  for all changes. Includes link to the GitHub Issue with :issue:`num`
  or this Pull Request with :pull:`num`. Includes contributor name
  and/or GitHub username (link with :ghuser:`user`).
• Pull request is nearly complete and ready for detailed review.
• Maintainer: Appropriate GitHub Labels and Milestone are assigned to the Pull Request and linked Issue.

[kandersolar]

Looks reasonable to me! A couple minor comments.

[kandersolar]

Just curious... these default values exclude the top 50% of values within each segment, right? I'm surprised that such an symmetrical window is a good default choice. What's the reasoning for it?

[kperrynrel]

@kandersolar this was experimentally derived, and meant to filter out noise. The original code did a 2/3rd cutoff to make the code more conservative about time shifts (we only want to suggest a shift if we're absolutely certain, and we want to error on the side of caution). Essentially this parameter allows the user to decide how cautious they want to be when estimating time shifts.