Add the simplest heap

[JalonWong]

A simplest heap is very useful on a resource-constrained platform and avoids the need to use heapless modules. Its usage is the same as other heaps.
Because it's the simplest implementation, it doesn't free memory. Any memory you drop cannot be reused (it's leaked), so avoid dropping anything whenever possible.

[zeenix]

Thanks you for adding a description to the PR.

Because it's the simplest implementation, it doesn't free memory.

It would be good to have an example use case here, where the existing impls would not be a good fit but this simplest impl would be better fit.

Any memory you drop cannot be reused (it's leaked), so avoid dropping anything whenever possible.

That seems like footgun and unsound behaviour to me. The example use case description should also document why this is worth having.

[zeenix]

Because it's the simplest implementation, it doesn't free memory.

It would be good to have an example use case here, where the existing impls would not be a good fit but this simplest impl would be better fit.

This is keeping in mind that the API remains almost identical to the user, they only have to pick one of the impls.

[zeenix]

Assuming we go forward with this new feature, IMO it should not be the default.

[JalonWong]

Because it's the simplest implementation, it doesn't free memory.

It would be good to have an example use case here, where the existing impls would not be a good fit but this simplest impl would be better fit.

@zeenix
I'm not sure what kind of example use case I can write. In some very small systems people just new instances and don't drop anything. Actually llff is good enough for most situations, which is similar to the heap4 in FreeRTOS. And this one is similar to the heap1 in the FreeRTOS. You only need it in a extreme situation.

You are right, this implementation is unsound, so I'm not sure if it's good to merge it into this crate. Maybe I can keep it private.

[zeenix]

Actually llff is good enough for most situations

That's what I was wondering. If llff can be used w/o any (significant) costs to the user in those scenarios, I think it's actually better if they use that instead. You may not be dropping anything in your code right now but code evolves and this is one part that can easily change. If you're using llff, you wouldn't need to worry but if you went for the simplest backend, you'll get into trouble. Also people make mistakes, so if we already have a safer backend, it's best to just stick with that.

so I'm not sure if it's good to merge it into this crate. Maybe I can keep it private.

Sure.