um.backend.waitEvents: scan all events; success false if no status

fix: a516061debb44e131c41729f439427fdc6ddd86b
userman events: provide ID arg for 'endwes@um' and 'out@um'
userman backend.waitEvents: gracefully handle `res` data parse errors
userman user status: identify component with 'um.usts'
userman user status: handle it in waiting events channel (wes)

The status of the user reflects connection and status info in both
UI and backend.

It is saved in `App.User.id` instead of autogenerated ID.
ID schema:
`status(4 chars) + user_id@remote_addr' 'session_id`
ID Example:
"awayolecom@127.0.0.1 y029tQqeTlvl2AJeecICdKUp"

Initial status is sent to backend while `wes` or `App.backend.waitEvents`
is initialized.

If status is changed via UI, backend receives this info via pending `wes`.

If some errors on UI or no new `wes` in backend happens, user status is
being set to offline. Further activity may restore status in UI from
`App.User.internalId` and then in backend via new `wes`.

`wes` events examples:

[{"ev":"auth@um","json":{"success":true,"user":{"id":"olecom","name":"Олег Верич","roles":["developer.local","admin.local","developer"]},"err":null,"can":null}}]

[{"ev":"usts@um","json":"onliolecom@127.0.0.1 y029tQqeTlvl2AJeecICdKUp"}]

rework of experiments in:
e23de720a0c99759d720fed28adb6084f1852e58
9013a2a292fcba67dd5e24fca14f5975b30e9504
um wes queue_event(): change callback coding style
um user status ev:'usts@um' waitEvents: fix identification of this user
um wes user status: refactor usage of `App.User.internalId`(tmp status store)
userman: various noop touches