ProjectOptions (public to private) & Project struct (org related fields) fixes

[DariuszPorowski]

This fixes#2110

• fixed ProjectOptions: Public -> Private (according to API doc: https://docs.github.com/en/rest/reference/projects#update-a-project)
• added OrganizationPermission and Private fields to Project struct, which presents during response on Organization Project.

I've done UATs as well, and all API calls looked good:

• Update Org Project with new private field
• Get Org Project (OrganizationPermission and Private presents as expected)
• Get Repo Project (OrganizationPermission and Private not presents as expected)
• Get User Project (OrganizationPermission and Private not presents as expected)

[google-cla]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[DariuszPorowski]

@googlebot I fixed it.

[codecov]

Codecov Report

Merging #2111 (77bc22d) into master (eefa002) will not change coverage.
The diff coverage is n/a.

@@ Coverage Diff @@## master #2111 +/- ##
=======================================
Coverage 97.77% 97.77% =======================================
Files 111 111 Lines 9934 9934 =======================================
Hits 9713 9713 Misses 154 154 Partials 67 67 

Impacted Files	Coverage Δ
github/projects.go	96.32% <ø> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update eefa002...77bc22d. Read the comment docs.

[gmlewis]

Thank you, @DariuszPorowski !
LGTM.

Awaiting second LGTM before merging.

This is technically a Breaking API change... however, I'm tempted to declare this one as non-breaking simply because what we are changing was already broken... so in theory, any attempts to use the prior version would have failed.

Thoughts? Is it OK to NOT declare this PR as a breaking APi change (and therefore not have to bump the major version number of this repo at the next release due to this PR alone)?

@willnorris - what is your opinion?

[willnorris]

Even though this was never working as intended, it's a breaking change in the Go API in that if anyone was calling it, their code would no longer compile now. And since it's been in the wild for 3 years, I feel like it would be more responsible to treat it as a breaking change.

[DariuszPorowski]

@gmlewis I agree with @willnorris
Even if it is a change to a valid GitHub API, it changes the entire usage of Go API.

[cpanato]

lgtm
we need to document that in the release notes

[gmlewis]

Thank you, @cpanato - merging.