docs: add a how-to guide focused on debugging charms

[tonyandrewmeyer]

This PR adds a new how-to guide that explains the tooling that's available for debugging charms. It's limited to what's available in Juju and jhack, plus an extra section that explains how to use VS Code rather than pdb. I haven't tried to be exhaustive with jhack, just cover the commands that seem most useful in general for debugging.

It does not include information about debugging K8s; I feel like that would quickly rabbit-hole into a lot of extra content, and, hopefully, Juju is sufficient in most cases, and, where not, there are other guides that can help with anything K8s-specific.

I haven't included anything along the lines of "ssh in and look around", as that seems a bit obvious and not a great practice, but I think it probably is actually fairly common.

In the index page, I've put it with logging, since they seem quite related; however, this does mean that it's quite high up in the sidebar listing, perhaps more so than it should be.

Preview

[james-garner-canonical]

This is great, Tony, thanks!

I do wonder if we should mention "ssh in and look around". It's pretty basic, as you said, but it might be good to make it explicit as a first step. Perhaps a sentence or two near the top, before or after the logging content, and an item in the numbered list at the bottom.

I've made a few suggestions. The two I would consider blocking approval are:

1. I don't think the Framework.breakpoint example is quite right, since (I think!) the breakpoint names need to match Juju events.
2. I think the VSCode debugpy recommendation could use breakpoint() where users want to insert breakpoints, and listen once at the top of charm.py.

[james-garner-canonical]

Approving because the two issues that I considered blocking weren't actually issues after all.

[tonyandrewmeyer]

I do wonder if we should mention "ssh in and look around". It's pretty basic, as you said, but it might be good to make it explicit as a first step.

Sure. David also reminded me that there's some Pebble debugging tools that should be mentioned as well, so I'll add that also.

Perhaps a sentence or two near the top, before or after the logging content, and an item in the numbered list at the bottom.

I'm thinking of dropping the bit at the bottom. It isn't necessarily the order you'd do things in, and it feels a bit filler, particularly given how long this already is (and I'm about to add two new bits). David suggested maybe having something like it at the top, but I feel like maybe that would just duplicate the ToC on the side. So I'm tempted to just remove it.

[tonyandrewmeyer]

@james-garner-canonical there's been a non-trivial amount of editing here, partly as a result of your suggestions, but also adding in the Pebble bit and dropping the bit at the end. Feel free to re-review if you like (but also fine to just leave it as-is).

@dwilding it should be good for review now - but no hurry! Thanks!

[james-garner-canonical]

New changes look great, thanks!