Updated to be wharf-api v5.0.0 compatible

[Alexamakans]

• I've added a new note in the CHANGELOG.md file, according to docs:
  https://iver-wharf.github.io/#/development/changelogs/writing-changelogs
• Wait for wharf-api v5.0.0 release
  • Do remaining work to support it.
  • Make sure import references wharf-api master branch again.

Summary

• Updated Go version to Go 1.16.
• Changed functions to match wharf-api v5.0.0 handler names, without the -handler suffix.
• Did some clean up, mainly through helper functions for making requests.
• Now using structs from wharf-api request/response packages instead of defining them here.

Motivation

Supporting wharf-api v5.0.0 faster and more smoothly when it gets released.
Keep up-to-date.

Not implemented methods

Methods listed in #31 are not implemented here, as it is out of scope for this PR.

---

Closes #24, closes #25

[applejag]

Looks great! I'm having second-thoughts about adding the dependency on wharf-api, but I don't see it being resolve in any other way without adding uncessesary complexity with yet another repo or whatnot.

The Go modules compatibility stuff is something we have to look closer into. Maybe a short meeting to resolve it?

I added a bunch of comments regarding the new Client.Get, Client.GetDecoded, etc. methods. I find them in a limbo between adding simplified abstractions and still being tedious to work with. I'll have to take a second look later for more comments, but here a meeting could be benefitial as well

[fredx30]

Looks good to me.

Is the prefer var syntax in the linting rules?

A sugestion - mixing refactor commits and change/feature commits in one PR makes code generally more difficult to review as they are hard to tell apart and require a different logic set to review. The sugestion here for future times would be split them up- ex. make one PR that tackles refactors, one that tackles removal of unused code, and one that tackles implementation of new features.

[applejag]

Regarding this:

Functions not implemented yet, mostly because I don't think we need them, but also because I'm unsure on how to.

• CreateBuildArtifact (Sending file(s) through multipart form data)
• CreateBuildTestResult (Sending file(s) through multipart form data)
• StreamBuildLog (Receiving a stream)

I'm OK with still leaving them out for this PR, as they were not implemented before either. Would be nice to have them implemented for v2, but I do not see that as a requirement and they could easily be postponed to v2.1.

Suggest creating an issue on it and then just referring to that in this PR, stating that it's out of scope for this PR

[applejag]

The Client.get, .getUnmarshal, etc series of methods are very practical. Each endpoint method still looks a little bit boilerplated but it's soooo much better than before.

Great work!