Add time frame for removal of deprecated tmr functions

[marcelstoer]

This came up while reviewing #1532.

[pjsg]

I hadn't realized that we had dynamic timers.... I must have lifted some sample code when I wrote my first app, and that used static timers.

[devsaurus]

A deadline is good for me, but it might be missed by users.

How about a notification message when static timers are being used, to warn users upfront? Like a deprecation "roadmap":
Next master drop E/November: message about upcoming removal (maybe 10 times after reset)
Drop E/January: static timer support finally removed

[marcelstoer]

I hadn't realized that we had dynamic timers

It was only added two months ago with #1424.

How about a notification message when static timers are being used, to warn users upfront?

Good idea. I obviously wouldn't know right now how to implement that but I'm convinced I'll figure it out.
I'll create a PR when I'm done. So, that shouldn't hold this one up.

Like a deprecation "roadmap".

Great! In the future we should add that to the release notes - which requires we establish one when a PR with API-replacements is merged. As long as we stick to our 2-months rhythm a 6-months deprecation time frame would IMO be fine.

[marcelstoer]

The thing with the notification message is being discussed in #1538.

But how are we going to proceed here? If there's a clearly defined time frame in the docs we must have someone willing to actually remove the deprecated stuff by that time. This being all voluntary we probably won't ever have that sort of commitment from anyone.

Therefore, I'm inclined to close this because it sets unrealistic expectations.