feat: instrument the snap charm library

[dimaqq]

This PR instruments the snap charm lib:

• subprocess calls
• HTTP calls to snap UNIX domain socket

This roughly follows Ops instrumentation paradigm, where hook tool and Pebble calls are traced on the process boundary.

Ref #160

[james-garner-canonical]

The existing unit and integration tests should make sure that we're not breaking anything here, but it might be a good idea to add something to the tests just to ensure that we can fetch the expected traces -- probably easiest to do that in the unit tests. The integration tests are not actually charm integration tests though, so if there's a lightweight way to check on the traces locally then the integration tests could be a better place.

[dimaqq]

Re: tests, I'm working on unit tests.
It turns out that a part of the code I'm changing was always mocked out, so I need to write more tests in general.

[james-garner-canonical]

I can accept the argument (made elsewhere) that if the OTEL API is being called correctly, we don't need to further test it. The improved coverage of these functions that were previously mocked out is a nice improvement, and ensures we cover the API call sites. I think these tests are sufficient as is, if it's a lot of work to interact with OTEL more deeply in tests -- and as mentioned, probably not something we should test directly.