Introduce Set interface & Each method

so, this is a little prep work, leading up to the goal of #7.

i've created a Set interface, and refactored the methods in the package to specify that, instead of `*Set`, as the type for provided parameters, and the return value in most cases. the side effect of doing this is that it's no longer OK to reach in and lock the mutexes in the provided object, as there's no guarantee that it's there. it seems this is the desired behavior if we're going to have a non-threadsafe set; one ought to be able to mix and match the two, no?

the bigger issue, though, is that it's not really possible any longer to directly reach in and `for...range` across the map storage of the passed set. to that end, i've introduced an `Each()` method, which is really just an iterator achieved via injecting a closure. (i think that's a useful addition, regardless). that's now used to do these traversals; the performance hit, based on the benchmarks introduced here, looks to be around 5%:

```
Through Each() (new):
BenchmarkSetEquality	   10000	    767576 ns/op
BenchmarkSubset	   10000	    786049 ns/op

Direct map iteration (old):
BenchmarkSetEquality	   10000	    723936 ns/op
BenchmarkSubset	   10000	    728652 ns/op
```
i also profiled this a bit, mostly just out of curiousity - results are here: https://gist.github.com/sdboyer/8447255 . that's profiling the `BenchmarkSetEquality` test. from that...well, i'm not even sure what to draw from it. but hey, there it is :)

bottom line - i thought we'd discuss whether or not you're OK with these changes before i proceed on to implementing the non-ts set. if so, the next step from here is fairly obvious, but i wanted to check in first.

also, side question - is there a reason you bookend the set methods with the lock/unlock calls instead of doing `defer s.l.RUnlock()` immediately after `s.l.RLock()`?