While looking at issue2550930, I looked at how template utils were being added.
I was able to dynamically add a function to the TemplatingUtils class using staticmethod().

So why was the code using instance.templating_utils to store the functions rather
than just adding them to the TemplatingUtils class. I think I know the answer.
Adding to the class modifies the class for all instances and leaks the new methods
to other trackers that may be served by other threads in the wsgi and roundup_server threaded
execution modes.

So I am implementing a similar method for registering methods that allow access to a TemplatingUtil.client instance for the request. This makes it a lot easier to call the util
from the template as we get the client instance with db, instance and other data for free.

To do this:

  1) make instance.registerUtilMethod add each method to the instance.templating_util_methods
     dict. Key is the name and value is the method/function.

  2) when TemplatingUtils __init__ is called, loop over the name(key)/method(value)
     and bind them to the TemplatingUtils instance with:
  
        self._bound_methods[name] = method.__get__(self)

  3) in __getattribute__ for TemplatingUtils, get the instances _bound_methods dict,
     see if the attribute name is in it and if so return the method.

A couple of gotchas. The registerUtilMethod and registerUtil have to make sure that
they can't add names that shadow the attributes of a TemplatingUtils.

So names beginning with _ can;t be registered. This protects self._bound_methods and self._
attributes. Also client shouldn't be rebound. I need the client attribute to look up
the instance.templating_utils and templating_util_methods dicts. If the attribute being
looked up is the client attribute, I return the client attribute immediately. So even if
somebody registers 'client', it won't be returned.

See attached patch. Comments welcome.