[fs-widget] Implement an alternative config pattern

[Aire-One]

Hello,

(This PR targets your 274-make-beatiful-optional branch)

I didn't have time to do this earlier, but at least, here it is: my take on making beautiful not a hard dependency for the fs-widget. (Also, please note this is untested)

My solution is actually quite easy:

You already have defined the (module level) global config table that holds all the available config properties and their default values. I trusted this table to set the local widget instance configuration table.
In the widget instance constructor, I add a _config table that holds the local version of the global config table. The local _config can be blindly used by the widget instance as "its own definition of configuration" ([1]).
I then replaced all the usage of the config table by the instance level _config table.

The main idea here is that the instance level _config table will be a copy of the global config table. With the exception, it's also checking for the first available value from args, beautiful, then fallback to the default.
(A notable limitation for this is that it will not work with nested table!)

Note: In the Awesome source code, we generally don't do a full copy of the default config table. Instead, we do the args or beautiful or default check every time we need to access the config value. We could have a debate on "what's the best approach: code readability/performance with a local config or save memory by doing the check". I personally think both approaches are equivalent at the end of the day...

[1]: Another approach with more complex widget would be to have something like self._private.config and some meta-table methods to properly implement getters and setters for these properties.

CC: @raven2cz

[streetturtle]

I really like this way! I'll test it and merge next week. Then will apply this approach on all the widgets.
Thank you!