fix recent change in behavior for "comp-lzo=no" setting

openvpn supports 4 different ways for --comp-lzo:
  1) no --comp-lzo option
  2) --comp-lzo yes
  3) --comp-lzo [adaptive]
  4) --comp-lzo no

Before commit 2ecf18c2, nm-openvpn
only supported 1) and 2). Those were expressed in NM's connection
by either omitting the comp-lzo setting or setting "comp-lzo=yes".

Arguably due to a bug, old plasma-nm would configure connections with
comp-lzo=no to mean 1), so after update of nm-openvpn to 2ecf18c2 those
connections changed to mean 4), which broke some existing configurations.
That was later attemted to be fixed in plasma-nm by commit [1], which
however only affects new connections and cannot fix existing connections
for users.

Ultimatley, the "comp-lzo=no" setting is spoiled due to that.

The fix is to add a new setting "comp-lzo=no-by-default" which shall
have the meaning 4) and pass "--comp-lzo no" to openvpn. A connection
with "comp-lzo=no" is again treated as 1).

This fixes old connections that were created by old plasma-nm before commit
[1] by restoring the old meaning.

This however now breaks users of recent nm-openvpn which were deliberately setting
"comp-lzo=no" to mean option 4), most notably users of recent plasma-nm (since
commit [1]). Users of the properties plugin for nm-connection-editor/gnome-control-center
are anyway unable to configure "comp-lzo=no" in the UI, so probably isn't a real
issue for many users.

plasma-nm bugs:
  [1] https://quickgit.kde.org/?p=plasma-nm.git&a=commit&h=31bcd5f2cffd1c19fbd10ab0f4172f2d82eff194
  https://bugs.kde.org/show_bug.cgi?id=365816
  https://bugzilla.redhat.com/show_bug.cgi?id=1365663

https://bugzilla.gnome.org/show_bug.cgi?id=769177
https://bugzilla.redhat.com/show_bug.cgi?id=1355688
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833166