Following rtslib/4f735bb86e8cef3de111d4ddff98695aeb35536e, we cannot use
RTSRoot.fabric_modules before loading the kernel modules.

To circumvent the problem, rtslib/93934a720968780b24ce03bb8e03d81f352d6662
introduced parse_specfile() and list_specfiles() which only require the
specfiles to be present on the system.

We used to mkdir the fabric modules configfs nodes after loading the kernel
modules. RTSLib does this already, so rely on it and remove that code from the
initscript.

When trying to stop an already stopped service, the initscript should succeed
and return 0. We now return 0 when trying to stop the target when
/sys/kernel/config/target does not exists. This also fixes a potential problem
when upgrading targetcli with the target stopped.

* In rtslib/61f72fd404eda5e263c2fd774db814dde5daa7cf, all module loading
  logic was removed from rtslib, and thus RTSRoot cannot be instanciated
  before the initscript loaded the target module.
* FabricModules.all() is a class method that only relies on specfiles

This allows to ease a little bit migration from development setups and legacy
lio-utils based installations. Configuration dumps only happens when starting
/etc/init.d/target if there is not pre-existing /etc/scsi_target.lio config and
the configfs target node is up.

* Initscript start detects migrations and saves running config
* Added lio-utils migration information in README.md

Attributes not described in policy files but existing in the installed kernel
modules can now be loaded by rtslib.Config, which means they can also be dumped
to the startup config. We must allow loading them also from there.

Also, the initscript can now load a config with new attributes.

It is possible that we include spec files with rtlib for fabric modules not
currently installed. A current example is the usb_gadget fabric module.

The target initscript will simply issue a warning when a fabric module
referenced in a spec file cannot be loaded.

Also, on stop, the initscript now tries to do as much as possible, even
if unloading something fails along the way.

This is an early preview of the next-generation targetcli based on the new
rtslib.Config API and the lio shell from the rtsli lio-config branch.

This mode allows editing a candidate configuration without impacting the
running system. This candidate configuration can then either be commited or
discarded at will. If commited, it will be applied to the running system and
saved as the new startup configuration.

Other features include loading a configuration from file, undo support,
rollback support, configuration backups and more.

This new mode is using a subshell not based anymore on configshell.
The plan is to introduce this new subshell in the next release, deemed as a
transition release, and eventually replace entirely the current targetcli UI,
when it will have reached parity with the current configshell both in terms of
features and quality of user interaction (colors, syntetic view of the system,
auto-completion, etc.). A basic standalone version of this shell is included
as targetcli-ng.

More information can be found in the target-devel mailing-list, notably the
"[ANN] LIO userspace improvements" thread dated 2014-02-27:

http://thread.gmane.org/gmane.linux.scsi.target.devel/5838/focus=5847

The code was manually ported over from the rtslib lio-config branch.

* System startup configuration is now done in this package, and both the new
  initscript and saving configuration from the shell (saveconfig) are using
  the new rtslib.Config API and the /etc/target/scsi_target.lio as config file

* The new initscript is a complete rewrite from scratch, and handles module
  (both core and fabric) loading and configfs initial configfs group creation,
  using rtlib.FabricModule specfile information

* Packaging update to conflict with lio-utils and ship the new init script

* Minor code cleanup in UINode.assert_root