Support pre-releases (alpha, beta, rc)

[Totktonada]

I'm going to close #19 with support of 2.10+ releases (2.10.0 and so on). This issue tracks additional work to support pre-releases like 2.10.0-rc1. I splitted the tasks, because I'm not sure about the best API for pre-releases.

What comes into the head first:

steps:
  - uses: actions/checkout@v2
  - uses: tarantool/setup-tarantool@v1
    with:
      tarantool-version: '2.10'
      pre-release: true

Or with exact version: tarantool-version: '2.10.0-rc1'.

Okay. What if I want latest 2.10.0 pre-release? tarantool-version: '2.10.0'? 2.10.0-rc1 is logically before 2.10.0, will not such tarantool-version confusing? OTOH, it is valid prefix and surely implements at least some of 2.10 feature set functionality. I'm not sure how we should interpret 2.10.0 in this context.

Next question. What if we want latest release or (if there are no release) latest pre-release of 2.10 feature set? We should be able to enable release and pre-release repositories both:

steps:
  - uses: actions/checkout@v2
  - uses: tarantool/setup-tarantool@v1
    with:
      tarantool-version: '2.10'
      <do not know how to name it>: ['release', 'pre-release']

We can also add 'live' into the list of possible values (for 1.10): so a user may have the ['1.10', '2.8', '2.10'] matrix of tarantool versions and acquire a latest available build this way:

steps:
  - uses: actions/checkout@v2
  - uses: tarantool/setup-tarantool@v1
    with:
      tarantool-version: ${{ matrix.tarantool }}
      <do not know how to name it>: ['release', 'pre-release', 'live']

What else to consider:

• The cache key is matched as a prefix (see also actions/cache key is not only about exact match github/docs#14145). 1.10 and 2.8 has the git hash in versions, but 2.10.0-beta1 is just 2.10.0-beta1, so it may clash with, say, 2.10.0-beta10. I guess we should add something to the end of the cache key.

I need to think around use cases and possible APIs here.