Made 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 merge and release of Updated to be wharf-api v5.0.0 compatible wharf-api-client-go#29.
  • Make sure import references that release.
  • Update CHANGELOG.md entry with the correct wharf-api-client-go version.
• Fix group and group+project name importing. GitLab endpoint seems to not work as expected.
  Related issue: (gitlab api/v4) search_namespaces option fails with error 500 from GitLab #42

Summary

Updated to use wharf-api-client-go v2.0.0, making it wharf-api v5.0.0 compatible, but dropping support for wharf-api v4.2.0 and below.

The testing code has not been updated and is therefore not functional currently. See Unresolved questions.

Motivation

Keep up-to-date.

Resolved questions

• The testing code has not been updated and is therefore not functional currently.
  If we want to keep it the way it is (updated so it works) then I can spend time updating it.
  Otherwise I will remove it, and we can come back to it when we have decided on how we want to write our tests.
  Should we spend time updating it, or remove it for now?
  • Updated, and some added for refreshing a project.

---

Closes #6, closes #42

[Alexamakans]

Currently runnable with go run ., Docker and GitHub builds fail because tests don't work.

[fredx30]

Seems to me as if this could be redrafted untill the testing issue i resolved.

[applejag]

Marking as "request changes" again to get it out of our PR tracker as still expecting changes

[Alexamakans]

Fixed tests.

No coverage increase. Due to changes in the code, coverage % has decreased. There should be no change to the paths that are tested though.

[applejag]

Lunchbreak between reviews, will continue to review later

[fredx30]

A bit hard to review- not entierly sure why or how some of these changes came about but if its tested im sure it will be fine.

[Alexamakans]

Mainly projects with spaces in their names broke, but I think it's also possible for the actual path to be different from the display name.

Added a fallback to search for the project by name and comparing groupName with the namespaces' different name variants.
This takes a fairly long time, but it does the trick.

This will also affect refreshing those projects, until logic for remote project IDs is implemented anyways.