Add missing close implementation, better naming of threads

[Crim]

This PR deals with mysterious orphaned Curator threads within tests.

• Add close() definition to SidelineVirtualSpoutHandler implementation that closes Curator.
• Remove un-used SpoutHandler instance in test.
• Add context parameter to CuratorFactory.

[Crim]

@stanlemon take a look see and merge if you see fit. I think the biggest problem was VirtualSidelineSpoutHandler was using the default close() implementation, and thus leaving Curator instances hanging around.

Side note around CI test times:

• Latest build against master took 8 mins 17 secs.
• This branch took 5 mins 53 seconds

Just as an FYI, the number of Curator instances is just about :todamnhigh: For the simple case of just running the Firehose, we now have a minimum of 4 Curator instances running, each spawning several threads themselves.

1 - SidelineSpoutHandler 2 - SidelineSpoutHandler -> ZookeeperTriggerWatcher 3 - Firehose VirtualSpout 4 - SidelineVirtualSpoutHandler

Do you forsee any way we can share instances between the sideline handlers at all? By design curator is threadsafe, and its intended to be shared across the JVM per cluster.