Compute overlaps data once

[juanedi]

Context

We noticed that a lot of the work needed to deal with overlapping highlights was being done once per highlightable even though it could be done once at the beginning of the view function.

⚠️ Important: the change doesn't have a noticeable impact on performance after another recent optimization that already made it so that we call this code waaaay less often than before. I still feel this simplifies things a bunch, so proposing the change mostly as a tidy-up refactor. Feel free to disregard if you disagree!

:framed_picture: What does this change look like?

Refactor with no visual changes.

Component completion checklist

• [x] I've gone through the relevant sections of the Development Accessibility guide with the changes I made to this component in mind
• [x] Changes are clearly documented
  • [x] Component docs include a changelog
  • [x] Any new exposed functions or properties have docs
• [x] Changes extend to the Component Catalog
  • [x] The Component Catalog is updated to use the newest version, if appropriate
  • [x] The Component Catalog example version number is updated, if appropriate
  • [x] Any new customizations are available from the Component Catalog
  • [x] The component example still has:
    • an accurate preview
    • valid sample code
    • correct keyboard behavior
    • correct and comprehensive guidance around how to use the component
• [x] Changes to the component are tested/the new version of the component is tested
• [x] Component API follows standard patterns in noredink-ui
  • e.g., as a dev, I can conveniently add an nriDescription
  • and adding a new feature to the component will not require major API changes to the component
• [x] If this is a new major version of the component, our team has stories created to upgrade all instances of the old component. Here are links to the stories:
  • add your story links here OR just write this is not a new major version
• [x] Please assign the following reviewers:
  • [x] Someone from your team who can review your PR in full and review requirements from your team's perspective.
  • [x] Component library owner - Someone from this group will review your PR for accessibility and adherence to component library foundations.
  • [x] If there are user-facing changes, a designer. (You may want to direct your designer to the deploy preview for easy review):
    • For writing-related component changes, add Stacey (staceyadams)
    • For quiz engine-related components, add Ravi (ravi-morbia)
    • For a11y-related changes to general components, add Ben (bendansby)
    • For general component-related changes or if you’re not sure about something, add the Design group (NoRedInk/design)