Refactor downsample algorithms

[NicMcPhee]

Specifying the type of downsampling via keywords (e.g. :ds-function and :case-rand) is very fragile and requires making changes to the core of the system whenever you want to change the approach to downsampling.

This commit changes that to instead have a downsample function specified in argmap. If no downsample function is specified, it defaults to using the training-data unchanged, i.e., no downsampling.

This arguably isn't "done done" because we still have to have the downsample? entry. If you set the downsample entry in argmap, but forget to set downsample? to true, things break, which is really annoying and Not Good. Unfortunately downsample? is used in several other places in gp-loop in ways I don't really understand at the moment, and until those can be changed we're stuck keeping downsample? for now.

That's why I've specified this as a draft pull request for now. If some folks can help me understand what's happening with all the different uses of downsample? in gp-loop, hopefully we can get this merged in.

I also need to find all the other test problems that use different flavors of downsampling and change their configurations so that they work with this change.

• [ ] Remove all references to downsample? in gp-loop.
• [ ] Update all example problems that use downsampling so that they work with this change.
• [ ] Figure out how to pass downsampling functions from the command line.

While I was here, I also made a few changes to the complex-regression example that I think substantially improve the solution rate for this problem. It also shows how we can use the new :downsample field in argmap to specify a downsampling function instead of just a bunch of keywords.