Start to implement API for relationships service.

This is still buggy.
Finish relationships service API.

Remove all the debug stuff and finish this implementation. The major change
in the handler is that we now expose the object type and if it is considered
'visible' or not in the results. It makes it easier for consumers to parse.

Usage of the API looks like this:

http://localhost:8000/api/v1/relationshipsservice/?ctype=Sample&cid=53cdd9e4d6fa25b059c54ddc&depth=1&types=Sample

The ctype and cid parameters are the CRITs type and ID of the starting object.
The depth and types arguments are optional. If depth is not given it defaults
to 3, and if types is not given it defaults to all top-level object types.

As is true of the graph in the UI, if the type of an object does not match the
list in the types parameter it is still collected and included in the graph,
but is marked as 'nvisible. This is so that the path to other objects related
to it is easy to follow.
Add type and visible to campaign nodes.
s/BucketObject/GraphObject/g
Add campaign tagging to relationships service.

If we traverse into a campaign go ahead and grab everything that is tagged
with that campaign, along with the related objects.
Remove unused file.
Always include label and URL in returned data.

Modify the javascript to not display the label if the node is marked
as invisible.

While here, remove an old console.log() call.
Merge pull request #26 from crits/relationships_api

Relationships API
Fixing TAXII 1.1 and STIX 1.1.1 support.

We now attempt to poll using TAXII 1.1 and if that fails we will inspect
the response to see if the server is trying to tell us that it is a
TAXII 1.0 server. If we determine it is, we will try to poll using TAXII
1.0.

Messages to the user in the interface are more verbose making it easier
to determine what happened.

We now use the appropriate STIX version constants for STIX 1.1.1.

Closes #27, #28.
Merge branch 'master' into distributed_services