Issue title: deprecate unary slice (error prone)
 Issue body: ## proposal
deprecate unary slice
https://nim-lang.github.io/Nim/system.html#..%2CsinkT

## rationale
it seems error prone eg:
```nim
when true:
  var b: array[-3..3, float]
  echo b[.. 2] == b[0 .. 2]
  echo b[b.low .. 2] == b[0 .. 2]
```
prints:
true
false

it'd be useful if `b[.. 2]` would be syntax sugar for `b[b.low .. 2]` (analog to `b[3..^1`) but it seems that all it does is being equal to `default(int)`, ie `0`.

I don't see the point of avoiding to type `0`.
 Comments: 
 Comment 0: Another argument in favor of deprecating: As far as I know only `b[.. 2]` but not `b[2 ..]` is a thing. This asymmetry feels a bit awkward, because in other languages slice boundaries are typically either mandatory or optional in both positions.
 Comment 1: It only feels "awkwardly" asymmetric when you look at it from an ignorant angle though. Nim simply doesn't have postfix operators so why would ``2 ..`` be a thing? Perfectly senseful design.
 Comment 2: It's ugly either way, information like a start index shouldn't be hidden, `b[0..2]` should just be syntax sugar for `b.slice(0, 2)` IMO.
 Comment 3: > It only feels "awkwardly" asymmetric when you look at it from an ignorant angle though. Nim simply doesn't have postfix operators so why would 2 .. be a thing? Perfectly senseful design.

No need to insult anyone. It is still a matter of expectation coming from other languages, no matter how sensible it is.
 Comment 4: Sorry, no insult implied.
 Comment 5: Nuke it from orbit.

 Comment 6: Again, "Accepted RFC" here means, "let's see what it breaks".
 Comment 7: I might be using this, I don't really like it but why remove it and whats the alternative?
 Comment 8: Fine. 0..x is easy to write as well.
{'source': 'GithubIssues', 'repo_name_with_owner': 'nim-lang/RFCs', 'issue_id': 783045619, 'repo_stars': 106.0}