Clipping for scrolling text didn't work properly when the control's height equals zero

The clipping for scrolling text didn't work properly when the height of the control was set to zero. This happens for labels only. The current constructor does not give them width/height automatically, so it needs to be compensated in the code later.

Added a condition to the clipping. When height of a label is <= 0 the height of the text will be used for setting the clipping region.
Lorem Ipsum text is too short to demonstrate vertical scrolling in Titant's settings Menu

Added a second longer lore ipsum for vertical scrolling demonstration to GUISettingsGUI_ScrollSpeed.cs
Updating Clipping in GUIFadeLabel to prevent wrong clipping when a negative vertical offset is used.

In some cases it can happen that a clipping regions position does not match the position of the text anymore.

This happens during ALIGN_CENTER of GUIFadeLabel.cs when no height is given. Therefore not the initial vertical position need sot be taken but the updated one as they now differ.

There is still one glitch left, where a scrolling line can jump up a few pixels once the scrolling beings. This is caused by the fact, that GUIFadeLabel, GUILabelControl, and GUIControl all manipulate the vertical position differently.

It is only visible when the vertical height is smaller than the one of the skin itself.  Happens because of constant type casting between int, float and double instead of proper use of rounding functions or using a dynamic variable and let C# automatically handle this properly.
Right most labels in Play List can be faded out.

When this issue was fixed for list views, it was forgotten to apply the same change zo GUIPlayListItemListControl.cs as well as it overrides the render text method of GUIListControl.cs
Updates to DefaultWide Skin for MP 1.3.0 RC
Updates to Default Skin for MP 1.3.0 RC
Removed a ")" that was too much in Titan's mypics.hiddenmenu.xml . It caused an exception in MediaPortal as the string couldn't be parsed anymore.
Crash when viewing a playlist

Recent commit of fixing the fading of the right most label when viewing a playlist caused a regression.

Reverting the changes and  providing a proper fix.

If the width of a text equals the width of the area it is rendered in, the skin engine fades the text.

This is either intentional or a ">=" instead of a ">" is used somewhere in GUIFadeLabel.cs to decide when fading should be done.

This behaviour is now compensated in GUIPlayListItemListControl.cs by adding +1 to the text width or else the last label would fade.
Mantis #4203

Adding additional clipping regions to prevent out of bounds rendering of labels.
Merge branch 'refs/heads/BUG-4118-Add_Padding_Property_To_Labels' into BUG-4187-UnfocusedAlpha_and_textures_in_ListControl