Sepiida

---
Update sepiida.storage to use woodhouse instead of s3 directly. The signature of the various sepiida.storage functions have changed, so be sure to check the source code and tests for exact usage. In general they are very similar, although a config object is no longer provided to the functions. Also some of the functions now expect a `bucket` parameter in addition of the name/key. Instead a `sepiida.storage` config option is expected to be provided as part of the service config. This config option should be automatically provided by the sepiida pillar, and should point to woodhouses dns location.

This also updates the `configuration` fixture to no longer be session scoped. This most likely will have little to no impact to tests, but could possible break tests which modify the configuration and then rely on those changes presisting to other tests.

-------
Various improvements to permissions fixtures

---

Add an optional method parameter to `sepiida.routing.uri` and add get method to `sepiida.storage.uri`.

`sepiida.routing.uri` can now be called with a method parameter, which allows one to build a uri for not only `GET` endpoints.

The get method to `sepiida.storage.uri` will allow files to be pulled from the storage layer. It takes an optional `output_filename` parameter which, if specified, will write the gotten file to a local file. Otherwise it will come back as an in filelike object, which can be read directly.

---
Add ServerSideEncryption and ContentType config options to sepiida.storage

These can be used to specify a ContentType and/or ServerSideEncryption for s3 put operations (both getting a link and directly putting). See the boto3 docs for a list of valid values for these options.

---
Add some extra test helpers for backend task framework

Particulary this should make defining tasks within a test for testing purposes much easier. Also it adds the `mock_task_factory` fixture, which can be used to create mock tasks which will patch an existing patch. Using `mock_task.ran`, `mock_task.task_args`, and `mock_task.task_kwargs`, you can ensure a task will be called correctly without actually running it in a test.

---
Add backend async task execution frame work

Internally this uses Celery, though that shouldn't really matter to the end user of this framework. It should only really matter when setting up a new backend.

The user will decorate thier backend tasks with `sepiida.backend.task()`, which also allows some arguments for controlling different aspects of the task execution.

To run the task in the backend, they will call it using the format `<task_name>.delay(args)`. The task can also be executed synconusly using its standard calling format, `<task_name>(args)`.

This also supports retry logic. For more details on that, see Celery documentation.

`sepiida.backend.create` is used to create the backend application. Somewhat counterintuitivly, this needs to be created as part of both backend AND frontend startup. This is because the frontend needs to know about the backend app to be able to delay tasks in the first place.

Finally this also includes a test fixture for testing backend tasks. The `backend_app` fixture should be used to test backend tasks. It creates a special backend app using the `testing` flag to put the backend into a sycronous mode, where as soon as a `task.delay` method is called, it will be executed imidately, instead of having to have a separate backend processes running. Examples of task tests can be found in tests/test_backend.py