Deprecate all packages in in-toto-golang

[shibumi]

This commit deprecates all packages within in-toto-golang and the most important methods.

[coveralls]

Pull Request Test Coverage Report for Build 14146477469

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.2%) to 71.437%

---

Totals
Change from base Build 14145833344:	0.2%
Covered Lines:	2316
Relevant Lines:	3242

---

💛 - Coveralls

[06kellyjac]

progress on #369

Glad to see this moving, just one thought.

[06kellyjac]

I understand having just "This method has been deprecated." for where there's a whole package deprecation note.
But for packages where only specific functions are deprecated so far do we want a longer comment which links to go-witness?

[shibumi]

I am not sure how far we want to go. At first I thought of putting the deprecation notice only on package level, but then I realized that many IDEs and code editors do not pick up these deprecation notices and they only pick it up for method comments.

Adding a comment to EVERY method seems really toilsome for me, so I tried adding it only to the most important method to make clear that we deprecate this.

We can link to go-witness from there as well, but I kinda want to avoid putting a big notice on every exported variable and method.

[adityasaky]

Maybe a slightly reckless solution, but I'm half tempted to cut a /v2 module release with just the stuff removed to see where the complaints are. My sense is that most of the consumption of this repo is for provenance / attestation structs and I'm curious if the workflows are in fact used. If we cut a breaking release and bump the major version, we can at least see who gets broken and determine if we want to cut subsequent 1.x releases?