Flat OPC Conversions

This is essentially the same pull request as this one: https://github.com/OfficeDev/Open-XML-SDK/pull/9. The difference is that (1) it is now on its own feature branch and (2) it is rebased on Eric's latest commit to master today. 

Documentation can be found in the discussion of the original pull request. 

I hope I've not messed up anything with rebasing and closing the original request. But I thought we should clean up, because at least the Flat OPC stuff might take a while to be merged into master. So I'm sorry if that created some issues, but I'm also learning git and GitHub best practices as we speak. 

Here are some sources that I found helpful, by the way:

* http://nvie.com/posts/a-successful-git-branching-model/
* http://blogs.atlassian.com/2013/07/git-upstreams-forks/

Based on these sources, here's what I did (where upstream is the name of your remote repo):

Firstly, I (essentially) rebased all my branches on upstream/master and reset the branches to where I wanted them to be. But first things first. With the following commands, I rebased master, which was a number of commits ahead of upstream/master and also contained all commits contained in feat/save-clone and feat/flat-opc-conversions. To be specific, master and feat/flat-opc-conversions pointed to the same commit and feat/save-clone was two commits behind (i.e., master or feat/flat-opc-conversions included the two commits with the Flat OPC conversion functionality). 

```
$ git fetch upstream
$ git checkout master
$ git rebase upstream/master
```

With the following commands I rebased the feature branches on master (which had been rebased already). I tried to rebase on upstream/master at first (I said I'm learning git, didn't I ;-), but that created another branch. So I just rebased on master again and that fixed it right away.

```
$ git checkout feat/flat-opc-conversions
$ git rebase master
$ git checkout feat/save-clone
$ git rebase master
```

However, at this point, all branches pointed to the same commit, so in hindsight, I should have rebased feat/save-clone on a concrete commit (I'm learning, right?). But that was easy to fix as well, as you will see below. 

```
$ checkout feat/save-clone
$ git reset --hard 4a28208146432047cb31be803e52a97eee1fffe5
```

This basically pointed feat/save-clone to the last commit of the series of commits containing the Save and Clone functionality. 

As I wanted to use the branching model described by Vincent Driessen (see link above), I thought it would be best to just keep my master in sync with whatever Eric has in the main repository. Thus, I also reset my master like this:

```
$ git checkout master
$ git rebase upstream/master
```

I then created a develop branch and merged my feature branches into this one. This way, I can have a single branch that contains all the new stuff that I've developed and based on which I develop my further Open-XML-Extensions. Here's how I did that:

```
$ git branch develop
$ git checkout develop
$ git merge --no-ff feat/save-clone
$ git merge --no-ff feat/flat-opc-conversions
```

Finally, I pushed all that to my fork:

```
$ git push --all -f
```

This should have changed the pull request related to feat/save-clone. So, again, I'm sorry if anything got messed up. But with this setup, we are now in a cleaner state. So, based on this cleaner state, I then created this new pull request. As the feat/flat-opc-conversions branch is built on top of the feat/save-clone branch, it also shows the feat/save-clone commits as a difference to upstream/master. 

Talking about upstream/master. This is currently the only branch in the central repository. Thus, you should probably create a develop branch as a pull request target and merge feature branches into that one rather than master. 

I'm describing what I've done because somebody might know how I should have done it instead. I know I could have used fewer commands here and there, e.g., `git checkout -b develop`instead of `git branch develop` plus `git checkout develop`. I'd really be interested whether I've done anything essentially wrong or whether my approach is OK.