another handful of fixes

[slingamn]

The individual commits should be mostly self-documenting.

[DanielOaks]

While I don't mind removing most of the indirection, I find it a little more interesting to explicitly need to declare the maps yourself now before safe use (unless you use the ApplyConfig, obv). Weird tradeoff of being indirect and having the maps defined for you vs direct and if you use 'em directly them you'll run into issues. Looks like it shouldn't be a drama though given how we use them (gosh I wish Go just make()'d the maps for you when you created a struct, that'd make it so dang easy).

[DanielOaks]

Great set of QoL fixes, thanks for the lovely PR

[slingamn]

Yeah, the pattern I've been going for in general is to replace NewBazBat() with func (bb *BazBat) Initialize(), which I have been thinking of as replacing one call with another (i.e., forgetting to call NewBazBat() is a nil pointer dereference, and forgetting to call Initialize() is some analogous panic), but the wider golang community and the stdlib seem to prefer the NewBazBat pattern and I'm not sure why.

I asked in #go-nuts about that map behavior and they called it autovivification and said it was bad, and I remember being moderately convinced at the time but I don't remember their arguments. ergochat/irc-go#11 did some autovivification-like behavior on the IrcMessage object (the tag maps became private members and were initialized only during the first relevant SetTag call).