Make Project a subclass of ProjectInfo

[ajkannan]

This is an alternate proof of concept for #530. This PR introduces the following changes:

• Project is now a subclass of ProjectInfo.
  • ResourceManager methods accept ProjectInfo objects but always return a Project
• A new abstract builder class is added to ProjectInfo. Both ProjectInfo.BuilderImpl and Project.Builder extend this abstract Builder.
  • The methods of Project.Builder delegate to ProjectInfo.BuilderImpl to avoid setter code duplication.
  • The abstract class is for code maintenance. If there is a new field for projects, adding it to the abstract class will ensure that we add it to both ProjectInfo.BuilderImpl and Project.Builder.

A user can create a ProjectInfo (without supplying a service object) when creating or updating a project. Since Resource Manager methods will return Project objects instead of ProjectInfo objects, the user doesn't have to supply the service object any additional times for the typical use case.

[ajkannan]

/cc @mziccard @mderka @aozarov

Thoughts?

[aozarov]

I like it! 👍

[mderka]

I need a bit more time to go through this. I follow up on Monday.

[mziccard]

I added a few nit comments. Great job @ajkannan I think this makes the API more usable without being verbose and keeps the code clean and maintainable. 👍

Btw, I can implement this in either bigquery or storage or both, just let me know!

[mziccard]

Looking a bit more into this. In bigquery we have a more complex situation where Info classes are part of a hierarchy.
For instance consider the TableInfo hierarchy where the BaseTableInfo class is extended by TableInfo, ViewInfo and ExternalTableInfo. Do you guys think this solution would still fit to the bigquery case?

[ajkannan]

@mziccard I'll take Storage and Resource Manager, and if you can take BigQuery, that'd be great.

I'll remove the "don't merge" label on this PR after I add changes to docs, fix the tests, and address the comments above.

[ajkannan]

Incorporated comments thus far and also updated README, javadoc, and tests. Ready for another pass.

[ajkannan]

Fixed more documentation issues and added a commit that adds a replace method with no arguments. This replace is useful because a common use case for replace is to use toBuilder on a project, which up until now required repetition. An example of the change would be:

myProject.toBuilder().addLabel("k", "v").build().replace();

rather than

myProject.replace(myProject.toBuilder().addLabel("k", "v").build())

Thoughts @mziccard @mderka?

[mziccard]

@ajkannan empty replace method looks good to me!

[ajkannan]

Added a commit to remove the original replace method.

[aozarov]

LGTM, please fix the doc issues we discussed before merge.

[ajkannan]

Fixed docs and re-tested sample in the docs.