Solaris/SmartOS: Handle services in maintenance

SMF has a concept of the maintenance state where the
system knows the service is broken which requires an
explicit "svcadm clear <service>"

"svcadm enable -s <service>" returns code 3 when the service
is in maintenance (-s means wait to see how enabling went)

Salt should notice a return code of 3, attempt to clear
the service and try to enable one more time.

Common use case is a broken configuration file.
The user pushes a fix to the config file with salt which should
clear the maintenance state and attempt to enable the service
again.
modules/smf.py: pylint fixes / cleanup
SmartOS/Solaris: fix SMF service management

fixes saltstack/salt#10702

The functions previously named get_enabled and get_disabled
actually only queried what services were running or not

This caused breakages where a state that both requested
"enabled" and "running" could cause salt to start the
service which would make it appear in the list of
enabled services, but not actually get enabled
and thus not actually come back up on reboot

Those functions have been renamed to get_running
and get_stopped

An accurate enabled function has been written
which queries the true property that determines
if a service will come up at boot
and disabled returns its negation.

New get_enabled and get_disabled functions have
also been written which accurately return the
list of enabled or disabled services
Those functions return full FMRIs (rather than the
much shorter 'SVC' column) because that's how
SMF actually works internally.
Merge pull request #10736 from nshalman/smartos-smf

SMF Fixes (SmartOS / Solaris)
fix moved ioflo gateway classes
Merge remote-tracking branch 'upstream/develop' into sam_raet_12
fixed conflict