update the slicing of padded arrays

[amoodie]

Padded arrays are used throughout the model for water and sediment routing. Two half-baked thoughts, mostly related to speed and simplicity:

1. are these necessary? I think they are created to be able to safely slice neighbors for any (px, py) pair in the model domain. However, the only place where this should really be needed is directly at the channel inlet, because sediment and water don't reach the domain edge anywhere else. Is there some way to rework the building of routing weights that just pulls from the "base" arrays directly, rather than the padded arrays?
2. the indexing of padded arrays is usually called with something like: self.pad_stage[px - 1 + 1:px + 2 + 1, py - 1 + 1:py + 2 + 1], which is written as such to account for the padded array itself (the +1 in each index), and the determining of the neighbors (-1 and +2). Note that the neighbors are given as -1 and +2 rather than -1 and +1 because python slicing is exclusive of the endpoint.
   The suggestion here is to eliminate this additional complexity and change slicing to self.pad_stage[px:px + 3, py:py + 3]. With this change, add a section to the developer guide about padded arrays and slicing these arrays, including the explanation above, and a reproduction of the figure below (in matplotlib?). Additionally, make a note in each method's docstring where the slicing was changed, that links to the documentation in the developer guide.

[amoodie]

A simple speed test shows that this may improve slicing speed too:

arr = np.random.uniform(size=(1000, 1000))
s1 = time.time()
for i in np.arange(996):
    for j in np.arange(996):
        _ = arr[i + 1 - 1, j + 2 + 1]
e1 = time.time()
s2 = time.time()
for i in np.arange(996):
    for j in np.arange(996):
        _ = arr[i, j + 3]
e2 = time.time()

addition: 1.1750993728637695
direct: 0.5617256164550781

Not sure this would make a difference in jitted functions though...