This is a lot easier to manage than having them in the code.
For now it piggybacks on the map hack feature, later this should use the same scripted approach as GZDoom.
This is by no means a permanent solution but having it buys some time to find something more universal that won't affect performance too badly and investigate the need for a more robust solution.
The idea here is to define pairs of walls where when the first element of the pair is seen, it will treat the second one as view blocking.
This is used as the two offending windows (sectors 151 and 152) to cope with the lack of a height sensitive clipper.
* let the clipper work on relative angles to simplify the math.
* properly initialize the initial visible range and preserve it for multiple invocations.
* track the maximum visible angular range per sector. While possibly not sufficient to handle every edge case imaginable it has low overhead and is still useful to eliminate obvious cases that do not need more complex checks. It is enough to fix the blue door in Duke E3L4.
* removed unused elements of the clipper.
* The loop for `userConfig.AddDefs` feels like it should be moved out of `loaddefinitionsfile()` and into `LoadDefinitions()`, but that's subject to discussion.
* Remove unused `getincanglef()`.
* Remove unused `getincangleq16()`.
* In `PlayerHorizon` struct, clamp value when setting target in `__settarget()`, not each public `settarget()` overload.
* Rename `PlayerAngle` method `applylook()` to `applyinput()`.
* Rename `PlayerHorizon` method `sethorizon()` to `applyinput()`.
* In `PlayerHorizon::applylook()`, slightly clean return to centre code so it doesn't do math if already at 0.
* In `PlayerAngle::applylook()`, slightly clean rotscrnang/look_ang code so it doesn't do math if already at 0 and reposition where mouse input is applied so that if input is applied, the player never enters a spin.
* In `Duke3d::player_struct::apply_seasick()`, use `buildfang()` method instead of scaling float to BAM within function.
