Document choice for using slower algorithm (#41)

#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.

Author: ebblake

src/year2021/day19.rs

@@ -213,6 +213,10 @@ pub fn part1(input: &[Located]) -> usize {
 pub fn part2(input: &[Located]) -> i32 {
     let mut result = 0;
 
+    // This solution uses the usual quadratic pairing of every point.  This is okay because
+    // the set is not terribly large, and the runtime here is dwarfed by the earlier runtime
+    // taken to get the coordinates in place.  However, a linear solution is also possible:
+    // https://www.reddit.com/r/adventofcode/comments/rygnl8/2021_day_19_part_2pseudocode_speeding_up/
     for first in input {
         for second in input {
             result = result.max(first.translation.manhattan(&second.translation));