Add REST endpoints for Feast UI

[SwampertX]

What this PR does / why we need it: In preparation for Feast UI (#834), we
need REST endpoints for Feast UI to consume. This PR creates such endpoints.

The below HTTP endpoints have been added to Feast Core:

HTTP Endpoint	Method	Accept Query Parameters?
/api/v1/version	GET	No
/api/v1/projects	GET	No
/api/v1/feature-sets	GET	Yes
/api/v1/features	GET	Yes
/api/v1/feature-statistics	GET	Yes

For query parameters on specific endpoints, please refer to the javadoc on each
method on the controller.

Which issue(s) this PR fixes:

Fixes #

Does this PR introduce a user-facing change?:
Yes

The below HTTP endpoints have been added to Feast Core:

| HTTP Endpoint                | Method | Accept Query Parameters? |
|------------------------------|--------|--------------------------|
| `/api/v1/version`            | `GET`  | No                       |
| `/api/v1/projects`           | `GET`  | No                       |
| `/api/v1/feature-sets`       | `GET`  | Yes                      |
| `/api/v1/features`           | `GET`  | Yes                      |
| `/api/v1/feature-statistics` | `GET`  | Yes                      |

For query parameters on specific endpoints, please refer to the javadoc on each
method on the controller.

[Yanson]

Do we really need a rest controller? How about grpc-web or grpc-gateway?

[woop]

Do we really need a rest controller? How about grpc-web or grpc-gateway?

@Yanson I am a little bit conflicted myself on which approach to take. I originally asked @SwampertX to use grpc-gateway, but after some discussion we decided to implement this as a REST controller. The biggest reason being that we didn't want to maintain another proxy and keep it in sync with our APIs, and I wasn't sure how well a gRPC proxy would play with our auth setup.

I dont feel too strongly either way though. Right now the goal is just to get a REST endpoint up so that we can continue development on the UI, however that is done.

Is your concern around code maintenance or dependencies?

[Yanson]

Is your concern around code maintenance or dependencies?

I'm not very opinionated on this as I haven't used either of my suggestions. It just seems like we might be creating work for ourselves and require maintaining parity with two sets of APIs.

I thought grpc-gateway was more automatic than you suggest, but my inclination would still have been to see if grpc-web gets us what we need (again, never used it myself).

[woop]

Is your concern around code maintenance or dependencies?

I'm not very opinionated on this as I haven't used either of my suggestions. It just seems like we might be creating work for ourselves and require maintaining parity with two sets of APIs.

I thought grpc-gateway was more automatic than you suggest, but my inclination would still have been to see if grpc-web gets us what we need (again, never used it myself).

Well looking at the code right now it does seem like its way more verbose than I would have liked.

[SwampertX]

/test test-end-to-end-batch

[SwampertX]

/test test-end-to-end-auth

[SwampertX]

/test test-end-to-end-batch-dataflow

[terryyylim]

/test test-end-to-end-batch-dataflow

[terryyylim]

/test test-end-to-end-batch

[terryyylim]

/test test-end-to-end-batch

[woop]

/lgtm