migrate log-smoothing to mini-library

[gfudenberg]

proposal: migrate log-smoothing code to a mini repository. https://github.com/open2c/cooltools/blob/0a7c01f9d186e36bb37cda22583e394fd0611e29/cooltools/sandbox/expected_smoothing.py#L81

why?

• cooltools, pairtools, and polykit all need smoothing of contacts vs. distance but shouldn't be each other's dependencies.
• each repository might have different desired presets for column names

design questions: -- operate on numpy arrays or some dataFrame with sensible present column names. -- argument in favor of operating on dataFrames: There is shared boilerplate for smoothing data in a DataFrame.

[golobor]

i wonder if we could consider expanding this proposal to migrate all application-agnostic numerical procedures (i.e. https://github.com/open2c/cooltools/blob/master/cooltools/lib/numutils.py ) into a separate library. Ofc, I know that we went through many iterations of such a library and there've been times when we though that it's messy and undesirable. However, I think, we can make this library clean and tidy if it were to contain only generic numeric routines and not library-specific codes. Thoughts?..

[Phlya]

I am not super keen on a "library" that is a random collection of unrelated functions... But we can discuss how it could make sense, i.e. for functions that are actually useful across other libraries, or if they use each other, or something like that...