Make specifying exts_defaultclass optional

[Flamefire]

It is NOT required when all extensions have either custom easyblocks or an easyblock key in their option dict.
In those cases exts_defaultclass is redundant making it harder to write the EasyConfig.

Check for a missing easyblock when actually using it so the error will be just a bit later but still (almost) the same.

One noteworthy semi-related change is the try-finally to the clean_up_fake_module call. We did that only when the exts_defaultclass was missing but not when anything else fails which looks like an omission. To keep at least the behavior for this the try-finally is required as the exception comes from init_ext_instances now. As a (IMO good) side effect it will also be called for any other error happening along the way, e.g. the similar error that the default easyblock is not found

Also some small drive-by fixes without any functional change to reduce the amount of linter warnings in the touched files.

Recent example usage for a CMakePythonPackage Easyconfig:

exts_list = [('%(namelower)s', version, {
    'easyblock': 'PythonPackage',
    'nosource': True,
    'download_dep_fail': True,
    'use_pip': True,
    'sanity_pip_check': True,
    'start_dir': '../python',
})]

But also applies if only software-specific easyblocks are used and we really don't want a default

[boegel]

@Flamefire I'll pick up on this again after the release of EasyBuild v5.1.0, since this change is way more involved than the last-minute regression bug fix being done in #4888 ...

[Flamefire]

Ok, I rebased this after #4686 caused this to conflict. And will again once #4888 is merged. Edit: Done

Although I think the change is not so complex: We only use the property in 2 places in a single file which are both modified here. So to me the change is very local.
And the current failure would IMO make a good test of this.

Or is 5.1.0 so immanent there is no time for that?

[Flamefire]

@boegel Ran into this again, can we merge this?