use optional kwarg for cols16 accross pywal API

[deviantfero]

this gives developers freedom in terms of choosing to use this option or not, making a transition between pywal and pywal16 smoother, moreover it adds a bit of consistency between cache_fname and color.get.

for now I have to do something ugly like:

    if __check_is_pywal16cols():
        filename = cache_fname(filepath, backend, False, False, WPG_DIR)
    else:
        filename = cache_fname(filepath, backend, False, WPG_DIR)

just to avoid not passing cols16.

[eylles]

yeh that will not be the only change needed... since now pywal has the contrast option...

so current master's cache_fname looks like this:

def cache_fname(img, backend, cols16, light, cache_dir, sat="", contrast=""):

while pywal's 3.3.0 cache_fname is:

def cache_fname(img, backend, light, cache_dir, sat=""):

that would mean slapping both cols16 and contrast into the same **kwargs dict ending up with an heterogeneous dict that contains a truthy string that can be lighten or darken and a float... now in cases like wpgtk it doesn't matter that the pywal16 API is uglier as things such as contrast and 16 colors are implemented inside wpgtk in it's own manner, but for those who want to use the pywal16 specific features OR simply collaborate to the project the codebase will come as more ugly and hard to read than already is, something i wanted to help by not just formatting the code with black but also start adding type annotations across the code, i hate to delay the release of pywal16 further but will have to since i want to both add type annotations and provide a more compatible API for programs using pywal as a library...