Implement minimal GitHub profile reviews API

[honzajavorek]

I decided that the backend part of juniorguru/junior.guru#1630 (comment) will live as part of the chick project. This means repurposing the project not only as a Discord bot, but also as a minimal backend API which serves tasks beyond Discord as well.

• Edit README so that it reflects the pivot:
  • "A real-time, synchronous junior.guru Discord bot and API."
  • The purpose of the API is to provide better user experience for website visitors, as the main website is a purely static site. If it doesn't work, the site should fall back to letting the user to do the job themselves manually.
  • The same as the Discord bot part, the API should have no state. It should only transfer information to and from other services, such as GitHub.
  • In places where we refer to the whole project, let's use "chick" instead of "bot" as a common name: "The main asynchronous codebase should monitor whether chick is up and running. If it's not, it should fail the build, but non-critically (similar to checking broken links in HTML)."
• GITHUB_API_KEY will be needed for the API part to work.

Currently chick already contains a HTTP server, which reports uptime status. Keep that. Apart from that, let's add two more routes:

• "POST /checks/{github_username}" (no data) creates a new GitHub Issue on https://github.com/juniorguru/eggtray similar to Zpětná vazba na profil @bashynx eggtray#260, but the initial text will be "Z webu junior.guru přišel požadavek na zpětnou vazbu k profilu @{username}." It returns JSON with two items: URL of the issue and its number as an integer.
• "GET /checks/{issue number} tries to load the issue from GitHub API and returns 404 if it doesn't exist. If it exists, it returns 202 if the check didn't finish yet. It returns 200 if the check did finish (no summary comment is present), and alonside it will return the JSON from the last summary comment available.

Use the https://github.com/yanyongyu/githubkit library as an SDK for working with GitHub API. Be resilient - prefer try/except around requests and logging error over raising (unless in debug mode) as it's important that the service stays alive and doesn't crash.