Create basic filters at startup if none are defined
Filter allows some environment fields for all items; Consistency check improved

* Allow filtering on environment fields HostName, UserName, IsInteractive, CommandLine and AppVersion for every FieldLogItem, taking the info from the most recent LogStart scope item of the same session
* Improved filter condition consistency check, checking at load time already
* Improved stability of filter logic in theoretical situations (using correct null checks now)
* Added support to filter for environment's HostName
Details view: Moved environment variables to the bottom
Handling and reporting errors while reading log files

Also, loading the log files can be cancelled with the Stop button in the toolbar.
Determine the missing full stack trace in the first chance exception handler
GUI message when many items are read quickly; Other related fixes, optimisations and changes

* Added and switched to load test scenario in ConsoleDemo
* FieldLogFileEnumerator.Append method instead of setting enumerator.LastReader.NextReader
* FieldLogFileEnumerator.Append waits to set WaitMode to false in case multiple files are created before the first of them has started to read which led to skipping items in live monitor mode
* Refactored some task lambda expressions into separate methods
* ReadWaitHandle is set every time all readers are waiting, not only after the initial read. The internal event (now ManualResetEvent) is also reset again as soon as a reader did read an item.
* Added some tracing to the log file reader classes (for now...)
* InsertSorted optimisation: For more than 100 list items, start searching more towards the end (speedup not yet verified)
* Loading message shows the number of items read so far
* MainViewModel: Replaced localLogItemsLock with a ReaderWriterLockSlim to prevent dead locks while waiting for queued items to be inserted and the new repeated ReadWaitHandle handler
* Post rate control: Don't push more items to the UI thread if more then 50 items are still queued
* Mass item in live monitor mode: If the UI thread is blocked for 0.5 s, it signals the read thread to stop sending single items and return to the localLogItems list used for initial mass loading.

The last item causes occasional GUI changes when lots of items are written to the log files at a time. While this is a lot faster than inserting each new item separately and should now be stable enough, it causes more and sometimes unnecessary user irritations. Other approaches (mass-sending items to the UI thread) are being evaluated.