Implement kernel functions to fill cubed sphere halos

[siddharthabishnu]

This PR implements kernel functions to fill halos of the cubed sphere, enabling cubed sphere simulations to run on a single GPU.

[siddharthabishnu]

Replacing

@apply_regionally begin
    launch!(grid.architecture, grid, kernel_parameters,
            _fill_cubed_sphere_center_center_field_east_west_halo_regions!, field, multiregion_field, region,
            grid.connectivity.connections, Nc, Hc)
end

by

for region in number_of_regions(grid)
    launch!(grid.architecture, grid[region], kernel_parameters,
            _fill_cubed_sphere_center_center_field_east_west_halo_regions!, field[region], field.data.regional_objects, region,
            grid.connectivity.connections[region], Nc, Hc)
end 

in src/MultiRegion/cubed_sphere_boundary_conditions.jl reduces the wall time of filling only the east-west halos of a CenterField on a ConformalCubedSphereGrid with one region of 128x128 cells per panel from

julia> @btime fill_halo_regions!(c)
  711.639 μs (714 allocations: 950.66 KiB)

to

julia> @btime fill_halo_regions!(c)
  13.371 μs (61 allocations: 14.83 KiB)

Upcoming commits will incorporate modifications of this type.

[navidcy]

I'm wondering if the loop:

for region in number_of_regions(grid)
...
end

can be done in parallel.

[simone-silvestri]

I would not incorporate those modifications but rather try to understand why that happens. The only difference there is the use of getregion instead of indexing with [region]. But getregion is intended to be basically just an indexing for the variables you have there, so it means that there is a problem with getregion, maybe a missing @inline somewhere?

In the end, with apply_regionally what happens under the hood is just this:

    for (r, dev) in enumerate(devs)
        switch_device!(dev)
        regional_func!((getregion(arg, r) for arg in args)...; (getregion(kwarg, r) for kwarg in kwargs)...)
    end

In this case regional_func! is the launch! function.