Dev/add xdoctest

[Erotemic]

Builds off of #218, in which there was discussion of moving to xdoctest as pytest doctest driver. This patch should accomplish that. It adds the appropriate dependency and sets the flag to enable xdoctest in the test command. I think that should be sufficient (lets see if the CI likes it).

---

On an unrelated note, I discovered this library due to its similarity to a package I maintain: ubelt. It exists in much the same spirit of boltons, but it has 90% less exposure, and is developed by 97% fewer people. I'm interested in merging parts of my toolset into this library. I think the organization of this package is well aligned with my tastes, and my tools might be of some benefit.

I'll make the appropriate PRs as necessary, moving only a single unit of functionality at a time (there are some things in ubelt that I don't see making it over here), but my entire API is in the README, so let me know if there is anything specific that looks interesting, otherwise I'll choose somewhere to start (assume you think this sounds like a good idea).

[mahmoud]

It's taken me a bit longer than I wanted to get to this, but so far so good. I definitely appreciate all the test fixes, all of which look good to me. The Travis is actually fine, too, despite what it may look like; that's just a PyPy bug that was reported and fixed (but I haven't gotten around to working around it in CI).

The only issue appears to be xdoctest must be taking a different approach to loading on Windows, because AppVeyor is unhappy. I see a bit of unicode struggle, but mostly some pyc messages. Did you want to turn the crank on this PR, do the usual CI dance and spam commits until it passes. No pressure, just saying we can always squash.

Also ubelt actually looks like it has some pretty cool stuff! Definitely a lot of overlap in functionality and architecture. I also like that you've sorted by usage :) I like compressuser (though technically shrink or maybe condense might be more antonymous to expand), and several others. Feel free to submit some in a separate PR when you've got the time. As far as priority, smaller/simpler and less opinionated are surer to get through :)

[Erotemic]

Is boltons planning on supporting Python 2.6 moving forward? I noticed xdoctest isn't compatible with Python 2.6. I did some work to see if it would be difficult to backport. The task was more work than I thought it would be, but I was able to the core runner working with 2.6, but I still haven't backported the tests, so I can't be sure that its right.

All though I did learn something interesting, I think I'd rather scrap that commit and maintain support for 2.7+. The limitation on '{}' in format strings (and to some extent the lack of set comprehensions) makes the code a lot more cluttered. If there is a strong reason to stay on 2.6, I'll finish the branch, but 2.7 is EOL in less than 2 months, so do you have thoughts / policies on dropping 2.6?