The bug is produced because of the following code:
if (methods.contains(Solid::PowerManagement::SuspendState)) {
    handleButtonEvents.writeEntry< uint >("lidAction", ToRamMode);
} else {
    handleButtonEvents.writeEntry< uint >("lidAction", TurnOffScreenMode);
}

There, SuspendState will NOT be contained in method, so we will fallback to TurnOffScreenMode.

LibSolid is always returning an empty "methods" (QList of SuspendMethods). LibSolid uses powerdevil
dbus api to know which suspend methods are available:

libsolid---dbus--->powerdevl-----backend---->UDisk

The problem is that the DBus interface of powerdevil is being setup AFTER generateProfile is executed, so libsolid
will fail to query powerdevil for the available suspend methods because powerdevil haven't made them public yet.

The approach in the fix:
There are many ways of fixing this, the simpler one is to execute the dbus registering before generateProfiles is executed,
the others are based on the same principle of moving the current code around to make libsolid work.

The reason why I went for a different approach is because it is architecturally wrong to have an interdependence:

PowerDevil------->libsolid------->PowerDevil.

No matter how careful we are, having this interdependence is going to cause problems sooner or later.

So, what I have done to keep the patch small is add 2 new arguments to generateProfiles (toRam and toDisk) so we don't
have to call libsolid in order to get this info.
I had to add these arguments instead of using PowerDevil::BackendInfo because generateProfiles is also used in EditPage.