Move 'hack' to the less confusing 'project'

We might want to break it up into smaller pieces (eg. tools in one
place, documents in another) but let's worry about that later.

Signed-off-by: Solomon Hykes <solomon@docker.com>

project/PRINCIPLES.md

@@ -0,0 +1,19 @@
+# Docker principles
+
+In the design and development of Docker we try to follow these principles:
+
+(Work in progress)
+
+* Don't try to replace every tool. Instead, be an ingredient to improve them.
+* Less code is better.
+* Less components is better. Do you really need to add one more class?
+* 50 lines of straightforward, readable code is better than 10 lines of magic that nobody can understand.
+* Don't do later what you can do now. "//FIXME: refactor" is not acceptable in new code.
+* When hesitating between 2 options, choose the one that is easier to reverse.
+* No is temporary, Yes is forever. If you're not sure about a new feature, say no. You can change your mind later.
+* Containers must be portable to the greatest possible number of machines. Be suspicious of any change which makes machines less interchangeable.
+* The less moving parts in a container, the better.
+* Don't merge it unless you document it.
+* Don't document it unless you can keep it up-to-date.
+* Don't merge it unless you test it!
+* Everyone's problem is slightly different. Focus on the part that is the same for everyone, and solve that.