mnesia: Synchronize lock cleanup after mnesia down

Bad timing could lead to hanging transactions after a mnesia down from a
node with sticky locks.

Excellent bug report from janchochol

Situation:
* node A and B have copies of table T
* node A ows sticky of table T
* node A goes down (e.g. crash)
* node B tries to perform transactional operation on table T
  (e.g. mnesia:select)

In this situation there is possibility that first (and maybe other)
transaction on node B will hang indefinitely.
This is caused by race condition, when transaction process send lock
request operation to node A and waits for reply. When node A is down
it will never send reply, so process on node B will be stuck
forever.
Reason is that message sent to mnesia_locker gen_server from
mnesia_locker:mnesia_down can be received after mnesia_locker gen_server
already replies to transaction processes with {switch, N, Req} and
node N is down.
Monitoring remote process when sending request to other node should
be safe solution.
Fix race condition in mnesia_monitor

Mnesia_monitor detect mnesia down using a remote process link
and net_kernel nodeup to detect that a node are reacable again.

If there is a short node communication problem.
The node-down and node-up events can happen before the
remotely linked process generates an 'EXIT'.
When node-down and node-up events are recevied they are
stored and later checked if the node came up just before
mnesia flagged the node as down.
Merge branch 'maint'

Conflicts:
	erts/etc/win32/Install.c
mnesia: Fix dirty_update bug when subscriber exists

dirty_update_counter returned the wrong value when a subscriber existed
and no events was sent. Thanks Anton Ryabkov.
Merge branch 'maint'
Prepare release
Merge tag 'OTP_R16B03'

The R16B03 release

Conflicts:
	lib/sasl/vsn.mk