Wrapped continuous spatial messaging

[Robadob]

Following #30, spatial messaging was added, however unlike FGPU1 new spatial doesn't currently support wrapping over environment bounds.

Wasn't added at the time as it doesn't fit well alongside strips optimisation, and best implementation would require a whole new version, rather than a device side flag/branch. This could be written within an hour or so, but seems overkill unless required.

[ptheywood]

Also add a reserved distance variable for warpped spatial messages.

Either a branch or templated specialisation.

[ptheywood]

To match array messaging, this would be accessed via FLAMEGPU->message_in.wrap() which returns a specialised message iterator which performs the wrapping.

For 2D and 3D spatial, providing partially wrapped iterators for cyclindrical / toridal environments may be required (but potentailly be a separate issue / feature, see #593 for reference)

[mondus]

Some thoughts on continuing this;

• Agents generally should stay within bounds and we can claim that messages outside of bounds are undefined behaviour.
• For wrapped. If values are outside of bounds when reading then they should be clamped by the user first. The wrapped iterator can then perform a check behind seatbelts for the undefined behaviour.
• Wrapping distance returned by iterator will always be the short distance
• Messages read over a boundary will have their original x, y, z positions
• The message type should have extra functions to provide virtual_x, virtual_y, virtual_z so that direction vectors can be calculated. The virtual position is the position if the message is moved to a halo region. The alternative would be to provide a relative position.

We have discounted the idea of a separate messaging type due to the amount of shared code that would be required.