Support coloring of tags with special characters

[hype09]

As described in #591, adding coloring to a tag tag-with-dashes via config breaks the configuration parsing:

tags.tag-with-dashes.color = black on yellow

Additionally, anything that comes after this line in the configuration file is no longer applied.

The reason for this lies in the way the configuration file is parsed, wrongly assuming that everything in front of the = is recognised as a single token by the lexer.

This pull request simplifies the parsing logic by checking if the current line contains a = symbol. If that's the case, the substrings before and after the symbol are treated as the assigned name and value. This also simplifies the case for settings with no value.

[lauft]

Closes #591

[lauft]

Looks good, however it seems to not work with the other config format.
When specifying colors like

define tags:
  SP+OC:
    color = white on red
  tag-with-dashes:
    color = blue on gray

the output of timew sum is uncolored... 🤔

[hype09]

I did not know of that other format yet - I’ll have a look 👍

[hype09]

Given the following configuration file content:

define tags:
  "Double quoted name":
    color = blue on gray
  'Single quoted name':
    color = red on white
  SP+OC:
    color = white on red
  SEPARATE WORDS:
    color = white on red
  tag-with-dashes:
    color = blue on gray

timew config will produce the following output:

define tags:
  "Double quoted name":
    color = blue on gray
  'Single quoted name':
    color = red on white
  OC:
    color = white on red
  WORDS:
    color = white on red
  dashes:
    color = blue on gray

I could do a similar change to what I did earlier, only for Rules::parseGroup, i.e. "take anything in front of the colon and trim the whitespace". This would help make the configuration parsing more predictable, but it's also a small BC break if people have things like SEPARATE WORDS: in their config and got accustomed to have it be parsed as WORDS:.

Do we need to be mindful of this or is it OK if the behavior for those edge cases changes to something more predictable?

[lauft]

Do we need to be mindful of this or is it OK if the behavior for those edge cases changes to something more predictable?

I guess the impact on existing workflows should be low (but you never know... 😅), so I opt for implementing this change 👍🏻