Reformat the source code

I'd like to get feedback about reformatting entirely the source code which I think would be beneficial for these reasons:
1. Quite often when a PR is submitted to Param it includes a few format changes (either because this is done automatically by a code editor or because the developer couldn't resists "fixing" the format of the code surrounding their changes). This is not ideal for the sake of git history and doesn't help code reviews.
2. I've opened two issues about improving the docstrings (https://github.com/holoviz/param/issues/588) and adding type hints to the source code (https://github.com/holoviz/param/issues/589). These changes if they happen (specially the second one) would touch a lot of code lines, I'd prefer this to be done on a clean basis, after reformatting (and to avoid what is mentioned in 1.).
3. Param has linting enabled except that it's pretty loose! Linting is of a good help when writing code (at least to me), reformatting the source code would allow to remove most (if not all!) of the ignored exceptions listed below. I'd also like to see the tests being reformatted and linting applied to them.
```
[flake8]
# TODO tests should not be excluded (one day...)
include = setup.py param numbergen
exclude = .git,__pycache__,.tox,.eggs,*.egg,doc,dist,build,_build,tests,.ipynb_checkpoints,run_test.py
ignore = E114,
E116,
E126,
E128,
E129,
E2,
E3,
E4,
E5,
E731,
E701,
E702,
E703,
E704,
E722,
E741,
E742,
E743,
W503,
W504,
```

And here are a few points against reformatting the source code, with my opinion:
1. The maintainers of Param may be used to how the source code looks and feels and don't want to see it changed not to disturb them or slow them down. Well this is a tradeoff, potential contributors to Param could also be disturbed and slowed down by how the source code currently looks and feels.
2. Parameters of a Parameterized class are usually declared following a common style (not described anywhere to my knowledge) that gets messed up when an automatic code formatter is executed. While I think this could be a problem for a large source code like Panel (although that's debatable) this would here affect only `numbergen`. I think the number of people who read `numbergen`'s code is pretty low, even more so now that it is [documented](https://param.holoviz.org/user_guide/Dynamic_Parameters.html#numbergen).
3. Reformatting the source code will touch a lot of code lines and thus have an impact on git history/blame. Yet I believe it is healthier if it happens in one go, instead of slowly at each new PR.