Refactor hashing logic

[eywalker]

Currently the configuration of hashing function is nested deeply, such that adding a new config option to the deepest point of hashing requires all the intermediate call methods to pass around new config option. This leads to extremely verbose API at multiple places, where many of the arguments are not directly relevant to the function.

For example, let: user_function -> middle_function -> deep_function be the invocation sequence. In order for the deep_function to implement a new configuration option new_config: int = 0, this keyword argument needs to be added to user_function as well as the middle_function, polluting the interface. To remedy this, consider reimplementing the function invocation pattern to use dependency injection pattern instead.

Briefly, this can be thought of as looking like:
user_function(..., mid_job=my_middle_function)
my_middle_function = partial(middle_function, deep_logic=deep_function)

This way, the deep business logic can be configured once and more intuitively outside of the invoking function(s), and the use of the injection function by the invoking function (i.e. use of my_middle_function by user_function) can focus on the function protocol instead of any details of the configuration.

[eywalker]

Partially assessed in #18 for file hashing. Object hashing refactor still pending.