Loggers tech is too wordy/scary

[DavidRieman]

We have methods like NotifySubscribers / UpdateSystemHost which are essentially fancy/scary words for Log. Further, the complexity of them is kind of buggy: For example, if a deep subsystem tries to log something, it can end up getting logged as the major system with no mention of the subsystem in play, since the this/sender chaining is confusing and as a result is rather incorrect. Further, due to the already-scary-seeming nature of these methods, it's hard to warrant building in standard logging features like "priority" systems where different final log destinations could register the level of verbosity they want. (E.G. an admin might want to see only infrequent and very important logs to the console window, but have lots of details go to text-file logs.)

For this ticket, we'll want to simplify the names and technology involved to ensure that we can still have a MultiUpdater (whether it retains that name or not) but using more common, simpler terminology like Log, while avoiding the this/sender stuff. Then consider tracking a ticket to build a logging priority system, with the default MultiUpdater demonstrating two sources accepting different, configurable log levels.