Close #408: No more direct sf::Color use

So, basically #392 continues. Apart from eliminating sf::Color, other
related small changes have probably also crept into this commit.

+ Fix #419: minor issue with the the demo (and test/main) wallpaper
  transparency slider.

+ Build: add -O0 -ggdb (and remove -O3) in mingw/DEBUG to help gdb'ing.

include/SAL/README.txt

@@ -1,27 +1,27 @@
-Service Adapter Library (or "Software Abstraction Layer", on every other day)
+Service Adapter Library (or "Software Abstraction Layer", every other day...)
 
 
 Like a HAL, but rather than standardizing an imaginary _underlying_ platform,
 the goal of this middleware layer is to facilitate replacing certain external
-components -- not just those belonging to a backend, but any libraries.
+components -- not just those belonging to a backend (but any libraries).
 
-The contents of this layer is diven by the needs of the application -- so each
-app should have its own optimal, tailored set of adapters. The app is free to
-decide to use SAL adapters, or integrate (or interface with) external services
-directly.
+The contents of this layer is diven by the needs of the application -- so, in
+theory, each app should have its own optimally tailored set of adapters in a
+layer like this.
 
-(So, it's neither "standardizing", nor hierarchically layered. That's why it
-hasn't become a "platform abstraction layer" (or PAL) either: not all services
-used are low-level, platform-like; the only common theme connecting them is
-just that they are meant to be easily replaceable without app rewrites.)
+So, it's neither an attempt at "standardizing", nor is it hierarchically layered.
+(That's why it's not a "platform abstraction layer" (or "PAL") either: not all
+services used are low-level, platform-like; the only common theme connecting them
+is just that they are meant to be easily replaceable without app rewrites.)
 
 ---------------------
 Actually...
 
 It could also be called even more generally a "Software Compatibility Layer",
 and then it could naturally also have a bunch of selected "utility" headers
-(and even modules, later -> overlapping a personal foundation lib!...) the
-app can still freely use, without any explicit "adaptering"!...
+(and even modules, later -> overlapping with a personal foundation lib!...)
+which apps can use directly, without any explicit "adaptering"!... (Which
+_does_ mean a kind of implicit standardization then...)
 
-And then all the truly generic crap buried under sfw/util (etc.) could finally
+And then all the legacy generic crap buried under sfw/util (etc.) could finally
 find a better home!

include/SAL/geometry/Rectangle.hpp

@@ -200,7 +200,7 @@ namespace SAL::geometry
 //----------------------------------------------------------------------------
 
 	template <typename NumT = float>
-	using Rect = Rectangle_Interface<adapter::/*geometry::active_backend::*/Rectangle_Impl<NumT>>;
+	using  Rect = Rectangle_Interface<adapter::/*geometry::active_backend::*/Rectangle_Impl<NumT>>;
 
 	using fRect = Rectangle_Interface<adapter::/*geometry::active_backend::*/Rectangle_Impl<float>>;
 	using iRect = Rectangle_Interface<adapter::/*geometry::active_backend::*/Rectangle_Impl<int>>;

include/SAL/geometry/SFML/Rectangle_Impl.hpp

@@ -60,12 +60,16 @@ namespace SFML
 } // namespace SFML
 
 
-// Save the specific adapter type to a backend-agnostic symbol...
-//namespace active_backend
-//{
+	// Save the specific adapter type to a backend-agnostic symbol...
+	//!!
+	//!! This looks totally useless, as this entire header is dispached by the selected backend,
+	//!! so things defined here could just live directly in adapter::, no need for SFML:: too
+	//!! -- but... The build system can't also dispatch the translation units yet, so it would
+	//!! just compile -- and link -- everything together, causing name clashes across backends!
+	//!!
 	template <typename NumT>
 	using Rectangle_Impl = SFML::Rectangle_Impl<NumT>;
-//}
+
 
 } // namespace SAL::adapter