Tiling improvments

[Aariq]

This follows the discussion in #83 and implements the version where tar_terra_tiles() takes a function name or anonymous function.

I like this because:

• You don't have to think too much about creating a list object
• It minimizes the number of targets the user has to create

Limitations:

• you cannot create a tile specification "manually" and supply it—you'd have to write your own helper function instead.

Possible tweaks:

• it might be possible to instead pass an expression. E.g. instead of tile_blocklist it would be tile_blocklist(my_raster) and instead of \(x) tile_n(x, 2, 2) it would be tile_n(my_raster, 2, 2) where my_raster would be the same SpatRaster object/target supplied to the raster argument of tar_terra_tiles().
• With that tweak, you could probably construct the extent object as a separate target and just pass the target name as that expression instead of a function.
• You could more easily screw this up though by accidentally using a different raster for your tile template.

Let me know what you think. If you like the idea, I can properly deprecate creat_tile_exts() which in this PR is renamed to tile_n().

[Aariq]

What are your thoughts on tile_n becoming tile_grid or tile_spec. To me, the n implies that I would suggest a total number of elements - similar to how in dplyr there is n_groups, n_distinct. Whereas in specifying a grid or a spec, we are suggesting that there is more information to be specified.

A tile_n function could then be specified that must be a square number, and that could then specify breaking it into n tiles. e.g., tile_n(4) would be a 2x2.

I am happy to write this out if you'd like.

tile_grid() makes sense to me. I think that should be sufficient and we probably don't need tile_n()

[njtierney]

tile_grid() makes sense to me. I think that should be sufficient and we probably don't need tile_n()

Great! I will open a separate issue to log the idea of tile_n() in case we think it might be useful later on.