Improve CRITs sharing via standards

*These changes are intended in conjunction with pull requests I have (or am about to) issue to `crits/crits_dependencies` and `crits/crits_services` with identical branch names.*

This may need some clean up, but functionality is here, so I wanted to get it PR'ed so review can start.

The changes I have made to the TAXII Service required some alteration of CRITs core source.

Highlights:
- Create `to_stix` method on base CRITs mixin that handles generating a STIX document for the crits object
- Add `to_cybox` code for `domains`, `emails`, `IPs`, `samples`, and `PCAPs`
- Add methods to said objects (and `indicators`) for providing information for `STIXHeader` when appropriate
- Update the `object_mapper` to convert more `indicator` types to available `CybOX` objects.

Regarding that last point, we need to review the **entire** large list and decide which items to drop (as there may not be a good or uniform way for us to put the limited data in the CRITs indicator (the `value`) into complex objects provided by `CybOX`) or to modify. In `object_mapper.py`, items that seem not to have any relevant `CybOX` object available have a `# TODO cybox-unavailable` comment. Items that have an object match that I'm not sure if/how to map have a `# TODO REPR` comment.

**Note:** we should DEFINITELY test to make sure that the upgrade of STIX and CybOX to the newest releases doesn't break other functionality in CRITs that depends on these.
What class/method are you thinking of? I defined these three methods on all supported crits object types (in this PR, emails/samples/pcaps/ips/certs/rawdata/events/indicators/domains). I went this route so that when `to_stix` creates a STIX document, it can populate the STIX Header with contextual information from the root object. 

If this isn't necessary/useful/manageable, we could remove these three methods from all of these classes and use some hard-coded information instead.