chg: move CustomSerializer into Engine

this allows us to make the CryptoEngine agnostic to the stored
data -- this should allow easy improvements for the metadata service
Encrypt metadata (index) too / work on bft f+1 / ss k confusion

Now metadata will be stored using CryptoEngine -- i.e. be encrypted.

ClientResult waited for f+1 results -- this is too low if we want to
do Shamir Secret Sharing. Actually this is rather ugly right now,
I really need to switch to robust secret sharing to make this work.

In addition the behavior should configure itself automagically --
somehow ClientResult should now the expected behavior is defined
by the used CryptoEngine. How to integrate this in a clean manner?
add initial S3 client interface

So far we're creating a fake bucket (fake_bucket) and allow every-
one to upload, list and download files from there. This was tested
with s3cmd:

| andy@MobileBastard:~/Downloads$ s3cmd --config=/home/andy/.s3cfg ls
| 2006-02-03 16:41  s3://fake_bucket
| andy@MobileBastard:~/Downloads$ s3cmd --config=/home/andy/.s3cfg put
| blub2 s3://fake_bucket/HashTag2
| WARNING: Module python-magic is not available. Guessing MIME types based
| on file extensions.
| blub2 -> s3://fake_bucket/HashTag2  [1 of 1]
|  28533 of 28533   100% in    0s   175.01 kB/s  done
| andy@MobileBastard:~/Downloads$ s3cmd --config=/home/andy/.s3cfg ls
| s3://fake_bucket
| 2006-02-03 16:41        42   s3://fake_bucket/HashTag2
| andy@MobileBastard:~/Downloads$ s3cmd --config=/home/andy/.s3cfg get
| s3://fake_bucket/HashTag2 blub3
| s3://fake_bucket/HashTag2 -> blub3  [1 of 1]
|  28533 of 28533   100% in    0s  1206.87 kB/s  done
| andy@MobileBastard:~/Downloads$ diff blu2 blub3
| diff: blu2: No such file or directory
| andy@MobileBastard:~/Downloads$ diff blub2 blub3
| andy@MobileBastard:~/Downloads$ s3cmd --config=/home/andy/.s3cfg del
| s3://fake_bucket/HashTag2
| File s3://fake_bucket/HashTag2 deleted
| andy@MobileBastard:~/Downloads$ s3cmd --config=/home/andy/.s3cfg la
use shamir for s3client example code

(otherwise we would just do simple mirroring)
improve compatibility with s3fs
remove ftp/file-based interface

By now we're offering the archistar-functionality through a
S3-compatible Interface (or through REST). This should be better
suited for users trying to access archistar. In addition we can
reuse much of the existing S3 specification and do not have to
reinvent the wheel.
extract XML-answer generation into a helper of its own

next step: unify FakeBucket and FakeRoot
delegate functionality from FakeRoot to FakeBucket

We need the header-based access method for usage with s3fs. Maybe
we can model FakeRoot as subclass of FakeBucket in the future (this
should remove all the 'forward-only' methods). I'd also like to check
against the presence of the bucket header within the HTTP request (
currently not done, as we only have one fake bucket)
Normalize S3 requests to virtual-style requests

Comment from RedirectorFilter:
/**
 * this filter should normalize incoming requests. S3 allows two ways of
 * addressing incoming requests: path style and virtual style. With this
 * filter all requests should be normalized to using a virtual style
 * request
 */
update documentation
Make the S3 interface 'more' S3 compatible

* now list bucket works
* remove the hard coded 'fake_bucket' bucket
* introduce dynamic bucket list (with 'fake_bucket' as only entry)

So now we should think if and how we would like to support multiple
buckets.
work on query capabilities for s3fs

By now at least some query cases should work. This should allow
us to list existing files as well as create empty new files.

Uploading/Downloading data is currently not working as resteasy's
REST implementation always returns 0 for HEAD queries. This disturbs
s3fs. A lot.
Merge pull request #15 from andreashappe/master

Enable more S3 functionality and disable other clients