Add steps in slicing syntax

# Extending F# Slicing Syntax for NDArrays (like Numpy)

This proposal is based on the assumption that slicing of multidimensional arrays (NDArrays) is an important part of being productive with numerics and that the Python Numpy is a good standard from which to draw from. The need for a more extensive slicing syntax becomes more acute when working with NDArrays. This proposal is for additional notation that will be useful in the creation of a future NDArray library.

Example 1: Remove border, rotate image, sub-sample, select specific color channels, and add a 'batch' axis.

Numpy

```python
rgb_small = bgra[np.newaxis,10:-10:-2,10:-10:-2,[2,1,0]]
```
FSharp

```fsharp
rgb_small =
bgra[10..-10, 10..-10,*]
|> NDArray.rev(axis=0)
|> NDArray.rev(axis=1)
|> NDArray.subsample([2,2,1])
|> NDArray.gather(axis=2,indexes=[2,1,0])
|> NDArray.newAxis(0)
```

NOTE: This assumes the NDArray library already supports negative indexing as per issue [#358](https://github.com/fsharp/fslang-suggestions/issues/358)

Problem: Step Sizes in indices (see also #518)
Proposed Solution: Seconding Prash's proposal of using the seq generator syntax of start .. step .. finish.

```fsharp
rgb_small =
bgra[10..-2..-10, 10..-2..-10,*]
|> NDArray.gather(axis=2,indexes=[2,1,0])
|> NDArray.newAxis(0)
```

Problem: Getting slices along an axis by a list of indexes
Proposed Solution: Possibly add List overloads alongside Option. In Python the use of a list of indexes is a subset of Advanced Indexing.

```fsharp
rgb_small =
bgra[10..-2..-10, 10..-2..-10,[2,1,0]]
|> NDArray.newAxis(0)
```

Problem: Using slicing syntax to insert a new axis
Proposed Solution: Perhaps a single case class called NewAxis

```fsharp
rgb_small = bgra[NewAxis,10..-2..-10, 10..-2,..-10,[2,1,0]]
```

There is a case to be made for supporting Advanced Indexing which would need to take an NDArray or NDArray in place of Option. Given that F# has better support for higher level functions than Python the need Advanced Indexing may not be as strong. Feedback form an informal poll of numerous F# users was that this is not important to them. I believe it's something to consider alongside the previous suggestion of List.

There is also a case to be made for supporting Numpy syntax ':' and '::' instead of the FSharp '*', '..' and '.. ..'. Again, feedback from an informal poll of F# users found that this was not important to them either. I think the Numpy syntax would be friendlier to non F# users. I believe this is something to consider.

## Pros and Cons

The Pros: Slicing is a common operation Data Science and with the growth of the Data Science field it's reasonable to expect it will become increasingly common. Numpy is a de-facto standard and I believe having F# slicing reflect Numpy's capability and syntax will go a long way to make using F# more familiar to Numpy users.

The Cons: It is an increase in complexity to the language. Hopefully this should be restricted to a narrow domain.

## Extra information

Estimated cost (XS, S, M, L, XL, XXL): L

Related suggestions: (put links to related suggestions here)
[More "python-like" functionality for List/Array slice syntax](https://github.com/fsharp/fslang-suggestions/issues/662)

## Affidavit (please submit!)

Please tick this by placing a cross in the box:
* [x] This is not a question (e.g. like one you might ask on [stackoverflow](http://stackoverflow.com)) and I have searched stackoverflow for discussions of this issue
* [x] I have [searched both open and closed suggestions on this site](http://github.com/fsharp/fslang-suggestions/issues) and believe this is not a duplicate
* [x] This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it.

Please tick all that apply:
* [x] This is not a breaking change to the F# language design*
* [x] I or my company would be willing to help implement and/or test this

* Depending on implementation. I presume any implementation would be additive.

No implementation files, tests, or entry points are named. Start by reviewing the proposed step sizes, index lists, NewAxis handling, and alternatives, then compare related issues #358, #518, and #662. Done would require a settled F# language-design scope rather than the several possibilities currently presented.

Written by the indexing model from the issue text.