Update to recent SSI

[sgreenbury]

Closes #85.

[edchapman88]

Do we have an approach to deciding whether to add contextLoader and other pass through variables with or without an Option wrapper?

pros for wrapper:

• Doesn't introduce new type into all the modules where the functions are used / easier to call the function elsewhere.
• So fewer mutable references passed around (in this case).

cons for wrapper:

• Have to decide on, and hard code a default if None strategy in the function implementation that is suitable for all use cases.

[sgreenbury]

Yes good point, open to modifying this if the current integration can be improved.

Adding a few specific options for including the ContextLoader in the API (other variants possible too) here:

1. context_loader: &mut ContextLoader: as used in the SSI-VC API (e.g. here)
2. context_loader: Option<&mut ContextLoader> : with option wrapping mut ref
3. context_loader: Option<ContextLoader>: with option wrapping moved context loader.

The current integration uses option 1. as it matches the SSI API directly and where no context loader is available adding a &mut ContextLoader::default() seemed not too much of a problem. On the mutable reference issue, we might face a challenge with a shared ContextLoader in the HTTP crate integrating it within the AppState (can be covered as part of #128), but we can wrap in a Mutex in this case (though should consider whether this would cause any performance issues, RwLock would probably be better as writing would probably not be required during operation).