Make GitLab Pages to use API

TL;DR This issue is about making GitLab Pages to talk to GitLab via API instead of using disk-database access.

I opened a comment in Eat GitLab Pages that describes an approach to refactor Pages to use API, instead of disk-based access to unlock Pages and solve a number of problems currently being part of Pages:

• complexity of the codebase: extending Pages is hard, as it implements a lot of business logic related to handling domains, groups and subgroups,
• long start-up times: traversing Pages database takes long time today,
• Geo/big-scale: change of architecture would enable us to feed pages with externally stored archives, served directly from .zip,

The attached comment describes all the architecture changes with the overall direction, and presents the following PoC to evaluate the complexity:

• Make Pages to use API
• The API interface on Rails
• Serve from .zip

Work-items

1. Ship legacy Pages with Omnibus (1.x.y): omnibus-gitlab!3098 (closed)
2. The Pages with the changes will receive 2.x.y version schema,