Document choice for using slower algorithm

[ebblake]

Description

#32 proposed speeding up 2021 part 2 to use a linear algorithm; but the pull request was closed unapplied because the savings were in the noise compared to the already time-consuming algorithm required in parse to even get to the point where distances can be computed. Still, it is worth documenting the approach as an aid to anyone else using this repository for inspiration.

Type of change

• Performance improvement
• Bug fix
• Other - documentation

Checklist

• Pull request title and commit messages are clear and informative.
• Documentation has been updated if necessary.
• Code style matches the existing code. This one is somewhat subjective, but try to "fit in" by
  using the same naming conventions. Code should be portable, avoiding any architecture
  specific intrinsics.
• Tests pass cargo test
• Code is formatted cargo fmt -- `find . -name "*.rs"`
• Code is linted cargo clippy --all-targets --all-features

Formatting and linting also can be executed by running just
(if installed) on the command line at the project root.

[ebblake]

I'm also wondering if you plan on reviewing the change in #30 to go from O(n^2) to O(n log n) for 2025 day 9 part 1 (that conversation kind of got sidetracked about whether part 2 should not use an input-specific O(n) hack in place of the O(n log n) general solution).