Avoid defining min/max macros from winmindef.h/minmax.h

[CraftedCart]

Avoid defining min/max macros from winmindef.h/minmax.h, since I was bitten by this trying to use std::numeric_limits<T>::max() in a mod I've been tinkering with. :P

• Everywhere we used to use min/max macros now uses std::min/std::max functions from <algorithm>
• Headers that include winmindef.h (eg: by including Windows.h directly, or through DirectX headers) now define both WIN32_LEAN_AND_MEAN and NOMINMAX if they weren't already defined, both to avoid the min/max macro pollution, and cut down on how much un-needed stuff from Windows.h gets included
• Source files that use the windows headers just define WIN32_LEAN_AND_MEAN and NOMINMAX directly at the top too now

[OrfeasZ]

Thanks for this! Instead of defining WIN32_LEAN_AND_MEAN and NOMINMAX in multiple places, you could instead apply them for the entire project by using add_compile_definitions() in the root CMakeLists.txt

You can leave the definition in Common.h so mods get it too, since that should be included in most places.

[CraftedCart]

Yeah that makes sense heh - though I do wonder if it might still be an issue if say, a mod includes Hooks.h before other things (which seems to include Windows.h* before* Common.h) :P

Maybe we consider that as a non-issue, since arguably a mod could define NOMINMAX itself if it wants to opt-out of that macro pollution? Not sure heh.

Anyway, I'll mark this PR as a draft then until I get round to that.

[CraftedCart]

Okie, moved the defines to CMakeLists.txt, shuffled around includes a bit in Hooks.h to make sure Common.h is included before Windows.h.

Also re-wrote the first commit to get rid of the the odd removed newline at EOF changes :P