Custom tag views

[raysarebest]

This provides a fix for Issue #142. This moves the applying of default stylings from a factory method in TagListView that's called in addTag(_:) to a method that just handles styling and is called in addTagView(_:) and insertTagView(_:at:). I also changed the implementation of addTagViews(_:) to call out to addTagView(_:) for each individual tag. Ultimately, this allows for the easy addition of custom subclasses to TagView. I added documentation comments for each of the relevant methods to make it clear that they unconditionally apply the styling of the TagListView that the TagView/subclass is being added to, so any individual tag stylization should take place after calling addTagView(_:), addTagViews(_:), or insertTagView(_:at:)

[anti-transmission]

I think tag is unnecessary here. Can you rename to stylize(_ tagView: TagView)? Also, there should be a space between TagView and {.

[raysarebest]

I learned something new about the style guide here. I personally like the argument label in cases like this, but it turns out the style guide recommends against it in most cases. Anyway, I fixed this in 5f7f661 and 67a4c0e

[anti-transmission]

With the change, rearrangeViews() would be called tagViews.count times instead of one time. Can you address that?

[raysarebest]

I addressed this in 892b412 by adding an extra argument to addTagView(_:) that specifies if it should call rearrangeViews(). It is true by default, so the impact to existing code both inside the library and in modules that imports it is 0. It's explicitly set to false inside this loop, and is called after the loop ends

[anti-transmission]

Looks good! With minor comments.

[FKSI]

👍 to the PR would love to see this one merged!

[FKSI]

@anti-transmission when do you think it will be release? :)

[raysarebest]

I just pushed some commits to fix the previous merge conflicts with the latest master branch, so I'd really love to see this get merged/released sometime soon (cc: @csvenja @Cee @xhacker @anti-transmission)