Send non zero repaint delay due to animation.

**Is your feature request related to a problem? Please describe.**

There can be slight flickering when side panel is enabled on a button click. Where the size of side panel gets adjusted.

According to docs, this is unavoidable.

> This is a fundamental shortcoming of immediate mode GUIs, and any attempt to resolve it comes with its own downsides.

> One workaround is to store the size and use it the next frame. This produces a frame-delay for the correct layout, producing occasional flickering the first frame something shows up. egui does this for some things such as windows and grid layouts.

In my own application, I can avoid that flickering easily by running the layout code multiple times (without sending output to gpu) until repaint_delay returned by Egui is non zero.

But this results in animations not working, as while it's animating the repaint_delay is always zero.

**Describe the solution you'd like**

This can be resolved if repaint caused by animation use a (very very) small repaint delay instead of zero.
From a simple look it seems that we only need to change Context::animate_bool to use Context::request_repaint_after(_, Duration::from_micros(1)) instead of Context::request_repaint.

And even logically animation frames have some time delay between them, no animation actually displays at infinite fps and zero delay in real life anyways.

**Describe alternatives you've considered**

Some api which describes that layout is not completely done yet vs layout is done.

Start at Context::animate_bool and compare its current request_repaint call with request_repaint_after. Reproduce the side-panel animation and inspect the returned repaint_delay; done means animation-triggered repaint requests expose a small non-zero delay without breaking animation updates or the existing layout workaround.

Written by the indexing model from the issue text.