feat: unundeprecate p- and q-adic methods

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 0% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 85.46%. Comparing base (b04719f) to head (4a9d4a6).

Files	Patch %	Lines
src/Deprecations.jl	0.00%	1 Missing :warning:

Additional details and impacted files

```diff @@ Coverage Diff @@ ## master #1758 +/- ## ========================================== - Coverage 85.48% 85.46% -0.03% ========================================== Files 95 95 Lines 36923 36922 -1 ========================================== - Hits 31565 31554 -11 - Misses 5358 5368 +10 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[thofma]

@benlorenz I have a feeling I have asked this before, but is there a reason that we do not run the downstream tests with depwarn=error?

[benlorenz]

@benlorenz I have a feeling I have asked this before, but is there a reason that we do not run the downstream tests with depwarn=error?

I don't really remember, maybe because I just used the default. For the testsuite we can probably add julia_args=["--depwarn=error"] to the Pkg.test calls (in OscarDevTools.jl). But for the doctests we might need to add this to the julia command in the yml file in the repositories.

[lgoettgens]

We don't run it with deperrors by default, since we had some issues in the past with external dependencies of use (like BinaryBuilder.jl) deprecating stuff and then all of our CI was red until we adapted and released all of our packages. In a post-1.0-era of our upstream packages, deprecations can be used in a normal release cycle as well. It's just in the pre-1.0-era that we can only deprecate stuff when making a minor release. But this is something that we can just look for ourselves I think.

[thofma]

OK, makes sense, thans.

[fingolfin]

"unundeprecate" 😂 maybe "re-deprecate" ? 😁