Route::read_wpt speed: going mutex-free, etc.

[yakra]

• [x] // strip whitespace in Route::read_wpt Leftover code from the early "translate from Python" days. We don't need to do this in C++, because strtok takes care of it for us. Tabs aren't permitted as delimiters; in theory they should not be in a .wpt anywhere.

  • [x] Run compare_all.sh to make sure there are no stray tabs at the ends of lines gunking anything up. ...Annnd there are a couple: nm.nm348.wpt has one, and pol.dk011sro has a line ending with a tab-tab-space. This means we do need the whitespace strip, as it's implemented now.
  • [x] Do need to fix the FIXME while I'm in there though, and strip whitespace from lines followed by a blank line (see also https://github.com/yakra/DataProcessing/commit/21f3ec9e18ffe5037764799b632c3fc3b7f53abc#diff-94cf8ff30938f93555463a110df06dacR94). This will make things a tiny, likely imperceptible, amount slower.
    

• [x] strtok_mtx Eliminate via strcspn and the "strtokless strtok".

  • [x] Raw Metal Speed: Will "strchrspn" have a noticeable effect at all? Meh, not a positive one. Ever so slightly slower, darn close to margin of error.
    

• [x] Route::awf_mtx This accounts for how much of our loss of efficiency after 8 or 9 threads? We can eliminate it by...

  • passing each instance of Route::read_wpt a list<string>* from an array
  • constructing filename via list::emplace_back
  • using a list::back reference for our ifstream & el
  • stepping thru the array & erasing its contents from all_wpt_files after ReadWptThreads finish.

  Quite like https://github.com/TravelMapping/DataProcessing/pull/311.

[yakra]

Removing Route::awf_mtx has no tangible effect. Single-threaded on BiggaTomato, we're 0.19s faster. In theory, we should be slightly slower, due to creating new lists and then iterating through them. BT @ 2thr 0.21s faster (the only change not obviously within this margin of error), BT & lab1 @ 3thr 0.13s faster, lab2 @ 1thr 0.18s faster; all other gains < 0.1s. lab2 is slower in 8/16 configurations; same speed in 2; lab3 slower in 19/24 configurations & unchanged in 1. Going to KISS & go no-build on this.

This tells me that hashing is pretty fast, and there's enough other stuff going on during a ReadWptThread to make the mutex locks pretty infrequent, making our losses from collisions pretty close to zero.