UnitRenderer uses the Visibility data from turn end, not turn start

[wraitii]

This is a relatively subtle race condition, discovered when testing ​Phab:D576 / ​Phab:rP24279

On RenderSubmit(), the renderer updates the visibility of units. This is good and well, except that it uses the "end of turn" visibility data. This breaks things rather subtly. Two cases:

• A fast unit that moves out into FOW over a turn should be "visible" at the beginning of the turn, then become invisible when it goes into FOW. However, since the unit renderer uses end-of-turn data, it becomes invisible immediately.
• A mirage that pops up will be rendered for a few frames before it receives a "visibility changed" message on the next turn.

The trouble is the code flow is as such:

• Start of turn N
• N Turn start -> unit renderer resets visibility to dirty, logs positions at turn start
• N turn Update -> RangeManager computes visibility updates, sends messages
• [Here be dragons -> code can trigger changes that need vis update, it's stored in m_visibilitydirty)
• N turn end -> unit renderer logs positions at turn end.
• Somes frames are rendered -> UnitRenderer calls GetLosVisibility, which is now seeing "end of turn" data.
• Start of turn N+1

I think this can only be fixed by doing two things:

• Moving the range manager visibility update to the turn start, to avoid weird data races
• Calling RenderSubmit once after turn start but before Update, so that entity visibilities are computed correctly.

This requires Splitting Update, which seems more complicated than I care to try right now, but probably makes sense.

[Stan]

Unlikely to get done for A26

[Freagarach]

Pushing back.