Remove the jacobian and primal_value primitives

[devmotion]

The jacobian and the primal_value support for @primitive does not provide any benefit but IMO rather makes the code less readable (related also to #91): The macro version is equivalent to directly defining AD.jacobian or AD.primal_value.

Hence this PR proposes to remove support for @primitive function jacobian and @primitive function primal_value (which seems unused and untested).

[codecov]

Codecov Report

Patch coverage: 100.00% and project coverage change: +0.74% 🎉

Comparison is base (041d760) 84.25% compared to head (2b321b0) 85.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master      #95      +/-   ##
==========================================
+ Coverage   84.25%   85.00%   +0.74%     
==========================================
  Files           8        8              
  Lines         470      460      -10     
==========================================
- Hits          396      391       -5     
+ Misses         74       69       -5     

Files Changed	Coverage Δ
src/AbstractDifferentiation.jl	80.51% <ø> (+0.85%)	⬆️
ext/AbstractDifferentiationFiniteDifferencesExt.jl	100.00% <100.00%> (ø)
ext/AbstractDifferentiationReverseDiffExt.jl	100.00% <100.00%> (ø)

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[oxinabox]

we should do this.
I guess it is technically breaking but since noone is using them, probably fine

[gdalle]

PR #93 is also breaking, and I'd like to break more stuff by tackling #53, so who cares? We can just tag 0.6 once we've done all that

[mohdibntarek]

I am in favour of breaking changes in this package and tagging a new release. I apologise for not being too actively involved here. Please tag team on this package without me and freely merge PRs if you all agree on the changes. I don't want to get in the way of progress here. Good luck!

[devmotion]

Could someone officially approve the PR? 🙂

[devmotion]

Thank you @mohamed82008! Makes me wonder though if we should adopt the colprac guidelines if more people are maintaining the package now (so far my impression was that basically everything should be approved by you 🙂)?

[mohdibntarek]

As the initiator of this package, I played the role of its maintainer for a while and then I got busy with other stuff and the package was not actively maintained. I think this package should be community-maintained since there seems to be enough interest and no time on my part to be the maintainer. I am not familiar with colprac guidelines for multiple maintainers. But I would say as long as 1 qualified reviewer approves the PR and no one objects in a certain time window, it can be safely merged. Happy to adopt any other standard folks are used to though.