CNavAreas have incorrect lighting information

The CNavAreas in the latest navigation mesh version (16) store 4 floats with a value between 0 and 1 representing the light intensity at the 4 corners of that CNavArea. When generated from a listen server the function CNavArea::ComputeLighting should be able to get the light and ambientColor at these positions and calculate the light intensity from these.

However, calls to "engine->GetLightForPointListenServerOnly" and "GetTerrainAmbientLightAtPoint" are annotated with the comment "// FIXMEL4DTOMAINMERGE" and commented out, and CNavArea::ComputeLighting will instead always return false on a listen server, meaning that regardless of whether the navigation mesh is generated from a dedicated or listen server, or the command nav_update_lighting is run, the light intensity values will always remain at their default.

Being able to calculate and store these values would benefit bot vision. Since all bot decision making is run server side, and there are no server side functions to get the ambient lighting at a position in the map, bots do not have any information about how well lit other bots or players are. If this issue was fixed, and a navigation mesh was generated on a listen server, bots could look to the navArea that either it or other bots/players are occupying to help inform their decision making, and reward stealthy gameplay with slower reaction times.

Start at CNavArea::ComputeLighting and trace the commented GetLightForPointListenServerOnly and GetTerrainAmbientLightAtPoint calls marked FIXMEL4DTOMAINMERGE. Verify how lighting is computed for the four corners on a listen server and how nav_update_lighting reaches this code. Done means listen-server-generated navigation meshes store non-default light intensities when lighting data is available.