Avoid breaking bindings when deserializing ReactiveObjects.

Since changingSubject and changedSubject were being overwritten, if
you had any binding on the constructor it would just vanish into thin
air whenever your subclass of ReactiveObject was deserialized.

An workaround would be to setup all your bindings on a [OnDeserialized]
method, however that is subpar when your deserializer supports running
constructors since it will lead to harder to read code and will spend
time creating the bindings twice (which is not cheap!).

This commit will avoid recreating these attributes while still supporting
deserializers that do not call constructors.

See also:
<https://github.com/reactiveui/ReactiveUI/commit/980107f55cadac02e14e10bb1c94d9b6dc5f05b5#commitcomment-4697090>
Avoid an unnecessary Subject/Multicast.
Use IReactiveNotifyCollectionChanged if available.
Changed NLog registration to use full class name.  This makes filtering NLog on the ReactiveUI namespace possible.  Also added a log message when creating a ReactiveObject which includes the hash code to make tracing easier.
Merge pull request #412 from reactiveui/fix-reactiveobject-deserialization-issue

Avoid breaking bindings when deserializing ReactiveObjects
Merge pull request #417 from reactiveui/derived-colls

Small improvements to derived collections.
Merge remote-tracking branch 'origin/pr/419'

Conflicts:
	ReactiveUI/ReactiveObject.cs
Add supported platforms

Fixes #423
Remove completely incorrect ObserveOn()s from CommonReactiveSource.

AFAICS with my current understanding of how threading is supposed to be
done on ReactiveUI, these ObserveOn()s introduced hazard windows even
if all of the user code lived on the main thread.

The problem is that using ObserveOn() means that the main thread queue
is going to be used.  If the user code does something like

    list.Add(...); // (a)
    list.Clear();  // (b)

then we are not able to guarantee that the changes introduced by (a) will
be processed by the UI{Table,Collection}View before (b) happens.  In other
words, it is possible that we tell the view to add the item after (b)
has already cleared the list, thus leading to an out of bounds access
on the list.  (Note that if we always used ReloadData(), then this would
never happen, since the view would not have any assumptions about the
state of the data it is displaying.)
Add some EnsureUIThreads in order to fail as early as possible.
Merge pull request #425 from reactiveui/race-fix-ii

Race Fix, 2nd attempt
Avoid NRE on CommonReactiveSource when the binding takes too much time.
Merge pull request #426 from reactiveui/binding-nre

Avoid NRE on CommonReactiveSource when the binding takes too much time.
Removed Pex from the list of test runners detected at runtime.Cleaned it up on 2 tests as well for consistency.
Merge pull request #428 from tiagomargalho/RemovePex

Removed Pex from the list of test runners detected at runtime
Remove the IList from IReactiveList<T>

This should not have been on the generic interface. It only belongs to
the generic implementation.

Fixes #427
Merge pull request #430 from reactiveui/haacked/reactive-list-interfaces-fix

Remove the IList from IReactiveList<T>