Turn on 3D FOV by default and combine its two options into one

[Qrox]

Summary

Interface "Turn on 3D FOV by default and combine its two options into one"

Purpose of change

Closes #71185. Fixes #63276. Closes #69053. Closes #58601 since I cannot no longer reproduce it (but it may have already been fixed before this PR).

3D FOV has been working fine for a while and I finally managed to fix the unit test errors caused by turning it on, so let's do it.

The old colored blocks display of the level below can be restored by setting 'Vertical range of 3D field of vision' to 0, but I don't think it is worth supporting multiple-level vision with colored blocks display because the main reason for the colored blocks display is performance and multiple-level vision is going to affect performance anyway, and fewer options make it easier to maintain the vision code.

Here's a list of previous behaviors (from my memory, didn't bother to test so do correct me if I'm wrong) and current behaviors. Most of the previous behaviors are still supported.

	FOV_3D	FOV_3D_Z_RANGE	Behavior & comments
Before multi-level rendering	On	0	Colored blocks & no z-level vision (Still supported)
	On	non-zero	Colored blocks & z-level vision (Not supported. Multi-levels are displayed instead. If performance is a concern, reduce the z-range value or change it to 0 to re-enable colored blocks)
	Off	0	Colored blocks & no z-level vision (Still supported)
	Off	non-zero	Colored blocks & no z-level vision (Changes into multi-level display)
After multi-level rendering	On	0	Colored blocks & no z-level vision (Still supported)
	On	non-zero	Multi-level & z-level vision (Still supported)
	Off	0	Colored blocks & no z-level vision (Still supported)
	Off	non-zero	Multi-level & no z-level vision (Not supported. Z-level vision is always enabled for consistent information.)
Now	On	0	Colored blocks & no z-level vision
	On	non-zero	Multi-level & z-level vision

Describe the solution

1. Removed the FOV_3D option and code for fov_3d == false. Unified handling of fov_3d_z_range in the process.
2. Fixed monster attack test by only allowing monster to stumble into the player when adjacent and properly implmenting the test for FOV_3D enabled.
3. Fixed the player activity interruption test failure that has been haunting us, by forcing the weather to WEATHER_CLEAR.
4. Fixed crash when moving or shifting view outside the z-level range.

Regarding 3; Turns out if the weather is changed due to previously run tests, the seen cache will be different. In this case the weather is mist, which seems to cause the player character to see through a wall column for a brief in-game second, which can also be reproduced in-game, and looks like #65205. The transparency cache also doesn't look right when the weather is clear in the test; z-level -1 seems to be considered to have the same transparency as air, although this problem does not happen in-game. I did not bother to fix these problems in this PR though; someone with more experience with the shadowcasting code should probably look into it.

Describe alternatives you've considered

Not doing this; Keep the FOV_3D option.

Testing

Ran the unit tests and they passed. Moved around in-game and the shadows looked reasonable. Tried to move character or cursor to z-level 10, they did not move and the game did not crash.

The filter that reproduces the player activity interruption test failure is [vehicle], activity_interruption_by_distractions.

Additional context

[PatrikLundell]

I believe #69053 remains a relevant hindrance.

[Qrox]

@PatrikLundell It seems the light map is only built on the player character's z level even with FOV 3D on, which caused NPCs to abort activities when the player character moves to a different z level. I worked it around by using the old behavior from non-3D-FOV mode, i.e. let NPCs continue activities when not on the same level as the player character. Building the light map for NPCs could be expensive, especially if there are multiple z levels with NPCs, so I didn't go that route.

[andrei8l]

The test npc_light_and_fine_detail_vision_mod can probably go. I made the wrong assumption there and it basically only checked that sunlight propagated down in open spaces.

[Qrox]

@andrei8l I changed the test to use the test cases from non-3D-FOV mode, but I think we can keep the test to ensure that no one changes fine_detail_vision_mod without also reworking lightmap generation.