Invalid log information from getOwnLog if peer doesn't 'own' the log

[carsonfarmer]

Creating a Thread on a (remote) peer/daemon doesn't require the client to provide the private key for it to be created. This is great, as it supports using the remote daemon/peer as a 'proxy' peer for doing 'trustless' log updates for a given remote client peer. Unfortunately, some of our existing internal logic assumes 'ownership' of a log is represented by having the private key. This is a reasonable assumption in many cases, but doesn't support the use case listed above. To remedy this, some more general concept of 'ownership' should be considered. In practice, this might look like 'flagging' logs created by the daemon/peer directly with a 'Direct' bool flag, indicating that this log is managed directly by this peer. To keep backward compatibility, we could still check for 'ownership' in the strict sense via the existence of a private key.