Revert introduction to subpackages for tests

[alexruiz]

For example, now all the tests for classes in org.fest.api are in different subpackages. We use the convention that tests reside in the same package (but different source folder) as the code being tested. Subpackages seem like a more organized way to have code, but in this case, I fail to see the benefit.

[joel-costigliola]

Even if I know Eclipse well, It was always painful for me to navigate in the tests packages that contained a lot of classes. If it was only me, I would not have moved the test classes in subpackages but some contributors made me the same remark. I won't fight more than that if you want to revert this but we should keep the refactoring part that removed the test duplicated code. Maybe we should vote for this one and hear what Ansgar and Yvonne opinion is.

[alexruiz]

The naming pattern of the test class names makes it easy to navigate directly to the test: ClassName_MethodName_Test. If tests are not in the same package as the class under tests, we cannot relax access modifiers in fields and methods from private to package-protected, but we would have to make them public. I strongly dislike the approach of having a superclass for tests. It makes the tests really hard to read.