refactor(builder): Don't track raw tags
refactor(builder): Don't track raw tags

When adding a string to the builder directly, it would parse the string
for formatting tags, delete them and readd them with the methods in the
builder that keep track of open tags so that we can properly close them
when flushing.

This parser has a bug, it parses multiple formatting tags in a single
block as a single tag, e.g.

  %{F#000000 u#FFFFFF +u}

would be parsed as an `F` tag with value `#000000 u#FFFFFF +u` which is
of course wrong.

Removing the parsing step fixes this problem in the simplest way
possible. This has two benefits:
* Building of modules is sped up because we don't have to do the parsing
step in the builder and many modules use this function to add strings
from a progressbar (which already has properly closed tags).
* We don't have parser logic in two places. Until now both `parser.cpp`
and `builder.cpp` actually parsed formatting tags. This leads to a lot
of code duplication and, as we've seen, bugs.

All of the modules that use this function to add text already make sure
that they properly close formatting tags (mostly by using the builder to
generate the strings)

NOTE: This change slightly changes polybar's behavior. Raw tags (tags
added by the user through the config) can now have their effects reach
neighboring modules because the builder doesn't track and thus doesn't
close them on each flush. This can (and will) be resolved by resetting
all tags at module borders.

Fixes #1555

jaagr/polybar,jaagr/polybar,jaagr/polybar