Changes

fix and refactor logging: drop 'with', simplify
With the recent fix of the junit report related issues, another issue
arose: the 'with log.Origin' was changed to disallow __enter__ing an
object twice to fix problems, now still code would fail because it tries
to do 'with' on the same object twice. The only reason is to ensure that
logging is associated with a given object. Instead of complicating even
more, implement differently.
Refactor logging to simplify use: drop the 'with Origin' style
completely, and instead use the python stack to determine which objects
are created by which, and which object to associate a log statement
with.
The new way: we rely on the convention that each class instance has a
local
'self' referencing the object instance. If we need to find an origin as
a new object's parent, or to associate a log message with, we traverse
each stack frame, fetching the first local 'self' object that is a
log.Origin class instance.
How to use:
Simply call log.log() anywhere, and it finds an Origin object to log
for, from the stack. Alternatively call self.log() for any Origin()
object to skip the lookup.
Create classes as child class of log.Origin and make sure to call 
super().__init__(category, name). This constructor will magically find a
parent Origin on the stack.
When an exception happens, we first escalate the exception up through
call scopes to where ever it is handled by log.log_exn(). This then
finds an Origin object in the traceback's stack frames, no need to nest
in 'with' scopes.
Hence the 'with log.Origin' now "happens implicitly", we can write pure
natural python code, no more hassles with scope ordering.
Furthermore, any frame can place additional logging information in a
frame by calling log.ctx(). This is automatically inserted in the
ancestry associated with a log statement / exception.
Change-Id: I5f9b53150f2bb6fa9d63ce27f0806f0ca6a45e90

log_test.py: cosmetic follow-up
This is kept separate to not clutter up previous patch 
I5f9b53150f2bb6fa9d63ce27f0806f0ca6a45e90.
Change-Id: I0ce50375fdb028da96c2159d577d8ed1967d4fe6

ofono_client: gracefully handle Scan() failure
ofono's NetworkRegistration.Scan() method fails sporadically. On
failure, check if we are now registered to the desired network, and
schedule another scan otherwise.
For instance it fails with org.ofono.Error.Failed if the modem starts to 
register internally after we started Scan() and the registering succeeds 
while we are still waiting for Scan() to finsih.
Change-Id: I4a2265ee39a94daa00f525b1c7037a6775509425