Add move_buffer_{left,right,start,end} commands

[emilyyyylime]

Closes #10278.
Default mapping: (let me know if you have better ideas)

• move_buffer_left: [[
• move_buffer_right: ]]
• move_buffer_start: [{
• move_buffer_end: ]}

#10077 was already closed as "encourag[ing] a more gui/mouse driven tab like workflow" but this is an even smaller and very straight-forward implementation.
If the Helix team truly wants to discourage this type of workflow this badly, why leave the gn/gp commands in?
#10278 shows there are a lot of users that would like this in Helix and personally at least I feel like I can get around faster by ordering my buffers spatially than by searching for them in a normally hidden menu every time I want to get to a different one.
With the ordered approach I just always know where my file is, it doesn't keep changing, so I know exactly which commands I need to use to get to it, without opening the buffer picker and scanning through it.

Implementation

I added indexmap as a dependency for a simple drop-in-place implementation.
I believe that a Vec should really be enough instead of any HashMap-like container, but after no responses from the team to my question on this matter, and a lot of friction in my attempts to switch a HashMap with a Vec due to how many places it was used in, I decided it's better to add a dependency than give up on this feature.
goto_buffer (used by goto_buffer_prev, goto_buffer_next) is also now noticeably faster with very high counts (which was never a real use case but)

[rahil627]

encourag[ing] a more gui/mouse driven tab like workflow"

hmmmmm... no wonder why tab is unmapped! or, well, maybe people map it to escape.. or maybe some keyboards don't have caps lock..!

just a thought: if this feature isn't possible, what if tabs were automatically re-ordered to most-recently-used/accessed too, to match the buffer picker? in it's current state, i see no point in accessing buffers whose tabs are wayy off-screen.. (though, this would destroy this feature ☹️..)