PPANMETH in pk.nca output

[Gero1999]

This PR allows in pk.nca function the addition of an optional PPANMETH column, which records the analysis method specifications for each calculated parameter. This helps users understand how each result was derived, such as the AUC calculation method, half-life selection, and any imputation performed. The change was documented and tested.

Closes #457

[billdenney]

Can you please change this from optional to always present? It can be ignored if the user does not want it, but it will keep the code simpler and not be a burden to the user to always create it rather than it being optional.

Please also merge in the current main branch.

[billdenney]

I'd rather that the method be applied within the calculation function rather than at the intervals level. That way, if we add more PPANMETH values in the future (e.g. first vs last cmax) it will apply directly.

Perhaps the best/easiest way is to make it work the same way that exclusions work now with an attribute on the returned object.

I'd also be open to having a ppanmeth = FALSE flag set for functions which would have them return a data.frame with PPANMETH, if TRUE. (Though I generally prefer consistent return value classes rather than return value classes that depend on input-- for ease of general use.)

[Gero1999]

I agree, this logical path seems better. I have some difficulties imaging these implementations. Lmk if you can help me, otherwise I will just try to address them naively:

attributes

1. The regular user won't check attr and will see output differences between pk.calc (attr) & pk.nca (col) that cannot be replicated
2. Most of the expect_equal tests associated with pk.nca results and derived obj don't ignore attributes.

ppanmeth = FALSE

1. Imputations should be indicated in PPANMETH, that also helps distinguishing the results from same intervals with different imputations. I guess it should be once per interval. If I follow the attr strategy I can see using vectors, but with the pk.calc(ppanmeth = FALSE) strategy then, how do I elude repetition?

[Gero1999]

Some aspects I noticed that I noticed in the original code that I am not sure if they are intentional:

• pk.calc.sparse_auc has a method argument that is not used, because the method for pk.calc.auc is always fixed to linear

• I get uncovered warnings in the tests that may be related with Warn on use of PKNCA.set.summary(reset=TRUE) #478:

Warning message:
In PKNCA.set.summary(reset = TRUE) :
  `reset = TRUE` is not intended for general use, summary() may not work after resetting summary instructions