feat(templates): add workload module to Kubernetes and machine profiles

[dwilding]

This PR update the kubernetes and machine profiles to include a standalone module for workload-specific logic. Other profiles are not changed in any way.

In addition to the new workload module, the updated profiles have a bit more structure in charm.py to illustrate the basic flow of logic through the charm & workload module, and improved unit tests in test_charm.py.

This PR includes

• New/updated template files for the kubernetes and machine profiles.
• Changes to charmcraft/application/commands/init.py, to determine the name of the workload module from the charm name (using workload.py if the charm has a generic name such as charm or k8s-operator).
• Changes to tests/integration/commands/test_init.py, to test the updated functionality (with tests passing).
• Updated help and output of charmcraft init, to make users aware of the workload module.
• New/updated reference docs:
  • src/<workload>.py file (new)
  • src/charm.py file (updated)

Hopefully it will be easy to follow my commits in sequence. I tried to make the changes in a logical step-by-step order.

[lengau]

Adding @mr-cal on this since he made the upstream version.

Callahan, how hard do you think it'd be to do this in craft-application? Maybe we could make the template filenames format strings that take a small dict?

[lengau]

Thanks for this PR David! Approving the template content themselves - I want to discuss the init changes and the docs with their relevant SMEs though before full approval.

[mr-cal]

@lengau, it's certainly possible to extend the existing design to allow for this. This is the second scenario where we have template-specific info. The other scenario is providing unique documentation links for each template.

I've been thinking about where this information could live. My current idea is a dict that we pass to the service, which maps template names to template data. That data could include a callables, for scenarios like this where the file renaming is complex.

Approving because the PR looks good and it can go upstream with some integration work.

[medubelko]

Thanks @dwilding! I left some suggestions for a bit of doc refinement, but overall these look fine to me.

[dwilding]

Thanks all for the reviews! @medubelko, I'll work on the doc changes first thing next week.

[medubelko]

Latest doc change LGTM.

[lengau]

LGTM, thanks!