Refactor into using a map for icon classes

[vanillajonathan]

No description provided.

[vanillajonathan]

@Ionaru Please merge!

[Ionaru]

Firstly, this is a project I maintain in my free time next to my day job. I look at all the issues and PRs, some take longer to look through and make a decision for. Please allow me the time for that.

Secondly, I'm not seeing the use of this change. Sure it makes a neat little variable containing all icons, but ends up being more code for the exact same effect. I rather like the current look of the toolbarBuiltInButtons variable as it shows how users can add their own custom buttons.

[vanillajonathan]

This PR serves as the underlying foundation for the next step.

Which is:

options.iconClassMap = extend({}, iconClassMap, options.iconClassMap || {});

Which allows integrators to easily use other icon sets without having to recreate every button themselves.

[Ionaru]

Then build what you want to build and provide the completed thing as a PR. Smaller increments through PRs only increase the risk of half finished functionality ending up in the source code.

[vanillajonathan]

Can this be merged?

[Ionaru]

I would prefer the iconClassMap to use the name property of the toolbar buttons because that is what the toolbar option uses as well.

[vanillajonathan]

Alright, done.

[willGabrielPereira]

Hi @Ionaru, this PR was made for exactly what? because it keeps doing the same effect, you can't change the icons even after this changes.

The #501 looks like really fix this. Please take a look in it!

[vanillajonathan]

@willGabrielPereira This PR was never meant to let you change the icons, it was just a refactor and a stepping stone to later expose it as options. See the comment #454 (comment) above.