Integrate Fontawesome icons

[maxmarkus]

I picked up an older issue since I am not happy with the colorful icons.
This PR would be a replacement for the old icons to use fontawesome.

How it looks:

Negation was not straight forward so there is a second method, alternatively we could go with a different colorset for negation (paid / not paid, checked in or out / not checked in or our)

Not sure which way to go - support the old and new way, then we would need to add a wrapper to provide two icon names.

My proposal would be full replacement as a startingpoint for discussions.

Resolves #346

[sonarcloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
32 Code Smells

No Coverage information
7.4% Duplication

[M4LuZ]

My personal opinion - up for discussion - is that it would be better to have the icon set as user-selectable option and support both (or even additional icons).
While I also do like the FA set, somebody else may want something either the original icon set or something else altogether.

Rough Idea:

• Completely standardise icon-names, so we have a mapping for all used icons
• maybe use derived classes to switch what is used without a ton of branch statements? (also with the option to refer to parent:: if there is no matching icon)

[M4LuZ]

I think this should also be $iconName, right?

[maxmarkus]

After I filed the PR I also thought that it might be rude to remove the old icons completely, since other designs might depend on it. Also, FA is only included in solid style which is free, regular seems not to have all icons and also the Pro styles could be used by someone.

I like the idea of a generic class that holds the icon mapping, which could be designed extensible so people could bring their own icon font to map it to icons based on the mapping the class provides.

One thing that is clearly different between original icons and fontawesome and this is the possibility to stack icons (eg for negation or creating custom icon styles (eg all icons are square with rounded corners and have the icon to be cut out, fontawesome.com/v5/docs/web/style/stack)

How would we treat new icons that are used in custom designs or modules, just by calling the icon method and if it does not get found in the mapping, it's passed through.
Default setting as configuration?
Provide an override which icon set to use?
Can there be a mix and match between different icon sets (looks ugly maybe)? That would open the possibility to use fontawesome and bring in custom icons that are not provided by FA but could be designed similar.

So many questions to answer, quite some api contracts to define :-D

[M4LuZ]

• Stacking: How about either extending the parameter $iconName? to handle arrays to support stacked icons or (what I would consider a better approach) define an additional method that sets a default set stored in an additional attribute to be always applied below whatever is then being passed during the concrete call? This would also work nicely with the approach of deriving this in a child class.
  e.g. add function $dsp->SetDefaultStack($stack).
  Orrrr...just throw it into an additional config parameter along with the icon design ;)
• Passthrough: Could be quite simple, unless I miss something: We throw the icons in a switch-case and default just calls::parent->fetchIcon() that then returns whatever does exist by default (and maybe logs that there is an icon mapping missing. Either by default or just in debug mode)
  If you want to mix and match then it should also not be a huge deal to define the class to use as fallback separately.
  We would then refer to the parent class as default value and replace that if needed

[maxmarkus]

Yep that sounds like a good plan. Unfortunately I got quite some things on my todo list already and those icons are not my highest prio for the next time. We can also close this PR and move the information to an issue, so anybody could work on it.