network: fix virNetworkObjAssignDef and persistence
    
    Experimentation showed that if virNetworkCreateXML() was called for a
    network that was already defined, and then the network was
    subsequently shutdown, the network would continue to be persistent
    after the shutdown (expected/desired), but the original config would
    be lost in favor of the transient config sent in with
    virNetworkCreateXML() (which would then be the new persistent config)
    (obviously unexpected/not desired).
    
    To fix this, virNetworkObjAssignDef() has been changed to
    
    1) properly save/free network->def and network->newDef for all the
    various combinations of live/active/persistent, including some
    combinations that were previously considered to be an error but didn't
    need to be (e.g. setting a "live" config for a network that isn't yet
    active but soon will be - that was previously considered an error,
    even though in practice it can be very useful).
    
    2) automatically set the persistent flag whenever a new non-live
    config is assigned to the network (and clear it when the non-live
    config is set to NULL). the libvirt network driver no longer directly
    manipulates network->persistent, but instead relies entirely on
    virNetworkObjAssignDef() to do the right thing automatically.
    
    After this patch, the following sequence will behave as expected:
    
    virNetworkDefineXML(X)
    virNetworkCreateXML(X') (same name but some config different)
    virNetworkDestroy(X)
    
    At the end of these calls, the network config will remain as it was
    after the initial virNetworkDefine(), whereas previously it would take
    on the changes given during virNetworkCreateXML().
    
    Another effect of this tighter coupling between a) setting a !live def
    and b) setting/clearing the "persistent" flag, is that future patches
    which change the details of network lifecycle management
    (e.g. upcoming patches to fix detection of "active" networks when
    libvirtd is restarted) will find it much more difficult to break
    persistence functionality.