Proposed change

This PR contains work towards addressing some concerns raised in #1559 by making holiday categories naturally integrated into holidays population logic (opposite of ad-hoc approach that was used when they were introduced initially).

It adds nullable HolidayBase::default_category attribute which defaults to 'PUBLIC' category at this moment. The default_category=None use case needs to be thought through -- please to add your input if any.

As holiday category blend into the base class structure the main focus remains on entity common and per subdivision holidays. All attributes/methods related to public holidays are now named explicitly (contain _public_ in theirs name).

Other changes:

• improve base class init args validation
• refactor observed holidays base class according to new parent's class structure
• refactor has_special_holidays and has_substituted_holidays as permanent HolidayBase attributes
• use _populate prefix for high-level methods (common/subdivision holidays)
• allow spaces in subdivision names
• update README, remove PUBLIC from supported categories column as it's a default one supported by all countries

Type of change

• New country/market holidays support (thank you!)
• Supported country/market holidays update (calendar discrepancy fix, localization)
• Existing code/documentation/test/process quality improvement (best practice, cleanup, refactoring, optimization)
• Dependency update (version deprecation/upgrade)
• Bugfix (non-breaking change which fixes an issue)
• Breaking change (a code change causing existing functionality to break)
• New feature (new python-holidays functionality in general)

Checklist

• I've followed the contributing guidelines
• I've run make pre-commit, it didn't generate any changes
• I've run make test, all tests passed locally