Improve parts features registration #1187

What needs to get done

The parts feature registration method needs to be more opinionated on how features are registered. A proposed solution would be the following:

• Create an enum, like PartsFeature
• Populate it with the possible parts features, like PartsFeature.PARTITIONS, PartsFeature.OVERLAY, etc.
• Keep two set[PartsFeature] attached to the application: _default_parts_feats and _requested_parts_feats
• Add two public final methods:
  • enable_parts_feature(feature: PartsFeature) -> None will add feature into the set of requested features
  • disable_parts_feature(feature: PartsFeature) -> None will remove feature from both the default features and the requested features sets
• Make _enable_craft_parts_features() final and have it enable the set of _default_parts_feats & _requested_parts_feats

Why it needs to get done

Currently, it is done in a hook where the implementers of the hook can decide the order features are enabled. We didn't design the API to be tight or opinionated enough, and now any changes may end up being overridden by a downstream consumer that didn't call super().