chore: cherry pick deprecation work from #26

[sbillinge]

Problem

Andrew's big PR on the GIL issue was resolved by Pavol but there is some work in there on deprecations that we may want to keep

Proposed solution

Go back through #26 to cherry-pick anthing we want from there

[zmx27]

@sbillinge how do we decide which parts of the PR we want to keep?

[sbillinge]

@zmx27 its a good question. I can take a look and give my feedback. @Sparks29032 is busy but if he has time maybe he can weigh in.

We are starting to deprecate things more formally now. @cadenmyers13 started this work. We have a deprecation class that is written in diffpy.utils that can be reused across all code that has diffpy.utils as a dependency. I want to update that a little so that the error message is built dynamically with a function that includes the full import of the deprecated function/class to minimize the typing of the person.

This is only needed for any API-breaking changes.

[Sparks29032]

@zmx27 @sbillinge
Everything looks fine to keep except the pyproject.toml. I do not think those other fixes have been implemented yet. If there are any conflicts let me know (make a PR).

[sbillinge]

Yes, I agree, I took a look. I was going to cross-check what had been implemented and what not, but this is easiest in a PR.