Add API endpoint to request contents of multiple files simultaniously

[denyskon]

Adds an API POST endpoint under /repos/{owner}/{repo}/files which receives a list of paths and returns a paginated list of the contents of these files.

This API endpoint will be helpful for applications like headless CMS (reference: sveltia/sveltia-cms#198) which need to retrieve a large number of files by reducing the amount of needed API calls.

[wxiaoguang]

Some thoughts in my mind:

1. Why it is a "POST" endpoint? If I understand correctly, it "GETs"
2. Does GitHub have a simliar API? If yes, we'd better to follow, if no, let's invent
3. It needs some tests (almost all existing APIs are covered by tests, otherwise it would easily break in the future if something changes)

[denyskon]

1. IIRC, the HTTP spec says or has said that GET requests should not contain a body - that's why it isn't an option. Post is the next best choice I think.

2. GitHub doesn't have a similar API, as such functionality is now being served through their GraphQL API. This, however, is clearly out of scope for near future, so I think that such an API endpoint would be helpful :)

3. I can add some tests...

[silverwind]

1. IIRC, the HTTP spec says or has said that GET requests should not contain a body - that's why it isn't an option. Post is the next best choice I think.

HTTP QUERY is a proposed standard to solve the GET-with-body problem. Tooling support is probably not there yet, but if it works in your case, it might be an option to use it already.

[wxiaoguang]

1. IIRC, the HTTP spec says or has said that GET requests should not contain a body - that's why it isn't an option. Post is the next best choice I think.

I see, I missed the Files []string field, it would be quite large so it is POST's job.