nestedness of grid code paths

[simonpcouch]

The trace back for dropping into tune_grid_loop_iter(), the layer of the grid code path that, for a given resample, carries out the preprocessor and model fitting, looks something like this:

1. ├─tune::tune_grid(...)
  ...
  3.   └─tune:::tune_grid_workflow(...)
         # does some checks, dispatches to `tune_grid_loop()`,
         # then calls `new_tune_results()`
  4.     └─tune:::tune_grid_loop(...)
           # makes allowance for agua, calls `pull_*()` functions
  5.       └─tune (local) fn_tune_grid_loop(...)
             # processes the parallel argument
  6.         └─tune:::tune_grid_loop_impl(...)
  ...           # sets up parallel resampling map, 
  21.           └─tune (local) fn_tune_grid_loop_iter_safely(...)
                  # `super_safely()`, calls 22., some error logging
  22.             └─tune (local) fn_tune_grid_loop_iter_wrapper(...)
  23.             # one more step, calling `tune_grid_loop_iter()` by the 
                  # above name ^^^

For tune_bayes() and tuning functions from finetune and agua, the trace back is deeper.

Debugging to tune_grid_loop_iter() is difficult because 1) it's not called by name and 2) it's nested so deeply inside the call stack. We should explore peeling back a layer or two and naming these functions in such a way that makes the order of dispatch clear.

I think fn_tune_grid_loop can be collapsed into tune_grid_loop_impl and/or tune_grid_loop up into tune_grid_workflow. finetune and agua will need attention here, in that case.

[simonpcouch]

Related to #866—this will be much more attainable once we don't have to maintain some foreach oddities.