refactor counts/pixelmap parser names and standardize usage

[Thomas Gilgenast]

load_primer_counts() is now the only supported way to read countsfiles, but many tools still use load_counts()

we propose to rename

• load_counts() -> load_counts_legacy()
• load_primer_counts() -> load_counts()

and standardize usage within lib5c to always use the new approach

similarly, get_primermap() should supersede get_pixelmap(), basically by moving

• get_pixelmap() -> get_pixelmap_legacy()

and making all of the following functions aliases of each other:

• get_primermap()
• get_pixelmap()
• load_primermap()
• load_pixelmap()

this is in line with the latest developments in modules2016

lib5c.tools.helpers.resolve_level() will become mostly deprecated since only lib5c smooth and lib5c expected really depend on the -l/--level flag

the pipeline will still carry around the level flag (it's never a free parameter in the pipeline context)

[Thomas Gilgenast]

major overhaul of counts/primermap parsing and plotting API

plotting API is now formalized in a new decorator: @lib5c.util.plotting.plotter

most plotters now follow this API, except for the old heatmap plotters and cluster heatmap plotters, as well as legacy plotters

primermap/counts parsing is now standardized in line with modules2016: only two functions are supported: load_primermap() and load_counts()

all tools have been updated to reflect this change

lib5c.tools.helpers.resolve_level() has been broken up into lib5c.tools.helpers.resolve_level() and lib5c.tools.helpers.resolve_primerfile() - this helper is only needed in a small number of tools

lib5c.tools.parents.level_parser has been broken up into lib5c.tools.parents.level_parser and lib5c.tools.parents.primerfile_parser - level_parser is used rarely while primerfile_parser is ubiquitous

this closes #23, closes #21, closes #18, closes #22, closes #11, and closes #9

→ <<cset f4e899afa042>>