Document how to tackle omniscent classes

What does this MR do and why?

In this MR I documented how to tame omniscent classes by providing guidelines on how to identify when it's the time to extract a separate class and some real examples on the strategy to use.

I also provided some generic guidelines how to stop adding new behavior to already overloaded classes such as Project and User and any files longer than 1000 LOC to at least be considered omniscent classes.

I found myself describing these patterns several times in code reviews so I believe it's worth documenting this as a software design guideline to follow.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.