[multibody] Deprecate FrameBase for removal

[jwnimmer-tri]

Amends #21853.

So although this is technically a breaking change I'm not deprecating it because there is ~zero chance anyone will be affected.

That's not the rules we agreed to live by. The rule is:

On very rare occasions it is impractical, too expensive, or logically unsound to meet the full three month deprecation window. In these cases the change will be announced in the “Breaking changes” section of the release notes.

-- https://drake.mit.edu/stable.html

This took me less than five minutes to fix. That is neither "impractical" nor "expensive".

---

This change is 

[jwnimmer-tri]

+@sherm1 for both reviews, please. High priority to fix this prior to the release this week.

[sherm1]

I'm not clear on what you did here, Jeremy. This just looks like undoing what I did before. I don't see any issued deprecation warnings? If someone were actually including frame_base.h directly or referencing FrameBase (extremely unlikely as I said before), they would still get no warning and then on 1/1/2025 they will get hit with a surprise breaking change. (IMO it would be miraculous if they actually saw the FrameBase comment you added.)

Did you intend to issue a warning?

The reason I think my tactic was consistent with the guidance you quoted above is that it would have taken me at least an hour to figure out how we are supposed to properly deprecate a header file that is going to be removed. I remember there is some way to do that but it has been so long I'd be starting from scratch. Given my belief that this is just busy work since no one in their right mind would be referencing frame_base, I think the expense is not worth the (lack of) reward.

Reviewable status: LGTM missing from assignee sherm1(platform)

[jwnimmer-tri]

I don't see any issued deprecation warnings?

Per our policy, the canonical inventory of deprecation warnings is the release notes, not the compiler warnings:

Deprecation announcements appear in the release notes for each stable release. For C++ and Python API changes, we will also use the language mechanism to highlight the change when possible ... monitor the release notes as the final arbiter of deprecation announcements.

-- https://drake.mit.edu/stable.html

Did you intend to issue a warning?

No. The release notes are sufficient.

The reason I think my tactic was consistent with the guidance you quoted above is that it would have taken me at least an hour to figure out how we are supposed to properly deprecate a header file that is going to be removed.

I agree you should not spend an hour on it. As you say, trying to use the C++ markers to flag this deprecation is very difficult because the base class is still actively part of our inheritance hierarchy, and because the header file is still included from our public code. Instead, you can pause and ask for help and I would have told you that one line of documentation and a PR label was all you needed.

[sherm1]

TBH I think this is a waste of time. However, x 2 if you insist.

Reviewed 3 of 4 files at r1, 1 of 1 files at r2, all commit messages.
Reviewable status: complete! all discussions resolved, LGTM from assignee sherm1(platform)