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.
Yup, I have a note a little ways down in that file telling myself to use the `class_from_id` method. I'm trying to figure out the best approach for enumerating which portions of the code work over which CRITs types -- I just don't want to hard-code the type strings in, in case they change in the future (hence why I kept the imports in for now, so I could use the `_meta['crits_type']` method on the classes.)