Proposal: Add context object accessible to bulder fns

[gavento]

Builder functions have limited access to anything but their input config and dependency entries. I can imagine the following may be also useful (not proposing to add all of this now, though):

• the runtime object
• the entry being created (in a wider sense)
  • record additional outputs (generic files, images, TF logs, ...) [I want to make this]
  • adding custom tags or information (logging?)
  • performance of certain blocks in the computation (e.g. via context managers)
  • online updates to progress (so it is seen in the DB and dashboard)
• the set of all requested dependencies
• get builder by name (from runtime)

This would likely be merged into _CONTEXT functionality.

Open question: how should builder fn get the context?

• First argument - IMO ugly and cumbersome for simpler functions, needs some more argument magic
• Function of orco, e.g. orco.ctx() - an explicit call (people will want to cache it) but semantically clean
• Module "attribute" like orco.ctx - even nicer, but modules can't have properties with getters.
  • We can have orco.ctx be a global proxy that redirects all attr access to thread-local objects ... buut may not be worth the extra fancy

[spirali]

I vote for orco.ctx()