Is your feature request related to a problem? Please describe.

Per #2073 , we are moving away from direct instantiation of Post, Term, etc. objects in favor of Timber::get_* methods. Using Class Maps, we want to make sure that the correct classes are instantiated for their respective post types, taxonomies, etc. To that end, we need to make sure these objects aren't instantiated directly, but are created in such a way that the proper hooks are applied before instantiation.

To this end, we need to disable instantiating calling these constructors.

Describe the solution you’d like

• Define a static Timber\Post::build() method that takes a WP_Post instance and returns an instance of the called class, e.g. a Timber\Post.
• Make Timber\Post::__construct() protected.
• Evaluate whether Comment, Image, Attachment, and PostQuery need to have their own special build methods and protected constructors.
• Repeat for analogs Term, Comment, Image, Attachment, PostQuery, Menu, and User as appropriate.

Describe alternatives you’ve considered

@gchtr threw out the question of whether it was possible to throw a doing-it-wrong exception if the constructor is called directly (presumably from outside Timber core). I don't know of a way to do this without either ephemerally setting global variables or checking the call stack (i.e. debug_backtrace()) from within the constructor, both of which would be very hacky.