FixedVec drain can implement DoubleEndedIterator

[eaglgenes101]

Unless FixedVec or its Drain iterator uses some weird tricks I am not aware of, it should be possible to iterate a FixedVec drain from the back as well as the front, much like Vec's Drain iterator, and with a similar strategy of reading an element from the end, then moving the end of the range of memory under the Drain's purview inwards.

[eaglgenes101]

...I see that HeroicKatora is ahead of me on this: #11

Now that I read the part about splitting off the issues when more specific implementation progress arrives... what should I do?

[197g]

Weird, Github didn't seem to ping be about this. Yes, splitting off that part into a tracking issue (this one) would be desirable. Then open a PR with implementation progress etc.

[197g]

Some guidance on implementation. The current Drain uses count and elements to keep track of the drain region. Compare this to the core implementation using a slice::Iter for that same purpose and restoring the start of the deinitialized region from the a pointer to the Vec. I don't quite specifically why I did not do the same but it was supposed to be a cleanroom implementation and a concern about adhering very strictly to stacked borrows.

https://github.com/HeroicKatora/static-alloc/blob/5894974dc2295eb2190c56b8cdad85383eecc23d/src/fixed_vec.rs#L103-L109

What's to do:

• Rename count to start, changing its doc to 'begin of the region yet to be drained'
• Split tail into tail and end where the latter is the 'end of the region yet to be drained', replacing self.tail with self.end where appropriate.
• Add as many tests as you can think of. At least on here. An exact drop count test as for fill is still missing for Drain so it would be neat to also have one for all usages there.

[197g]

Fixed in #21