Signed-off-by: Sergio Schvezov <sergio.schvezov@canonical.com>

Signed-off-by: Sergio Schvezov <sergio.schvezov@canonical.com>

The correct location to add craft-parts Features is a bit tricky:

- it must happen soon enough that things that happen early have the correct
  features enabled. For example, building the default command groups takes
  into account whether overlays are enabled;
- it must happen late enough that the craft-cli logging support has already
  been set-up.

Therefore, provide a method that Application subclasses can override to enable
their features, and the Application itself takes care of calling it at the
correct time.

The (new) rule is this: in validators, always raise the types that Pydantic
expects (ValueErrors, AssertionErrors, TypeError, and subclasses of these).
This allows Pydantic to capture all errors and group them into a single
ValidationError, which we can then convert into a single CraftValidationError
in from_yaml_data(). This provides a more uniform UI for the reporting of
validation errors on the project.

Ensure that each error message starts with a lowercase letter.

This way the validation errors get correctly translated and converted into
CraftValidationErrors.

This is mainly used for validation errors: when a CraftBaseModel fails to be
created due to Pydantic validation errors, the link to that specific model
class is added to the error message shown to the user.

Signed-off-by: Claudio Matsuoka <claudio.matsuoka@canonical.com>

Now that the 'rockcraft' work branch has been merged and released we can fix
the version constraint for craft-cli and craft-parts.

This workflow is similar to starbase's current one, with a few differences:

- It uses self-hosted runners;
- It uses Trusted Publishers to publish to PyPI;
- It constrains the artifacts that are attached to the GH release.

This is a partial revert of 0115c28; apparently actions/checkout's
"fetch-tags" property is broken and gives errors at checkout time.

Ref: actions/checkout#1467