[workspace] Flag sdformat, ignition_math, ignition_utils as internal

[jwnimmer-tri]

We are substantially patching these libraries to weave them into Drake. We should not give the illusion to users that they are available for reuse downstream.

Also take this opportunity to track the ignition => gz project rename.

Towards #17231.

---

This change is 

[jwnimmer-tri]

+@rpoyner-tri for feature review, please.

Reviewable status: LGTM missing from assignee rpoyner-tri(platform), needs at least two assigned reviewers (waiting on @rpoyner-tri)

---

tools/workspace/deprecation.bzl line 1 at r1 (raw file):

# -*- python -*-

FYI This file is copied from #17229. It will disappear here once we rebase.

[rpoyner-tri]

Reviewed 20 of 20 files at r1, all commit messages.
Reviewable status: 1 unresolved discussion, needs at least two assigned reviewers (waiting on @jwnimmer-tri)

a discussion (no related file):
Do the ignition_*names in tools/workspace/new_release.py also need to change?

https://github.com/RobotLocomotion/drake/blob/9c9e57540876545172baf70ac955bdb497171227/tools/workspace/new_release.py#L68-L69=

---

[jwnimmer-tri]

+@sammy-tri for platform review per schedule, please.

Reviewable status: 1 unresolved discussion, LGTM missing from assignee sammy-tri(platform) (waiting on @rpoyner-tri and @sammy-tri)

a discussion (no related file):

Previously, rpoyner-tri (Rick Poyner (rico)) wrote…

Do the ignition_*names in tools/workspace/new_release.py also need to change?

https://github.com/RobotLocomotion/drake/blob/9c9e57540876545172baf70ac955bdb497171227/tools/workspace/new_release.py#L68-L69=

Done.

Right you are. I also missed qhull_internal in the prior PR, fixed here now as a follow-up.

---

[rpoyner-tri]

Reviewed 4 of 4 files at r2, all commit messages.
Reviewable status: 1 unresolved discussion, LGTM missing from assignee sammy-tri(platform) (waiting on @rpoyner-tri and @sammy-tri)

[sammy-tri]

Is there a guideline for when we should be using cc_library vs cc_library_vendored for _internal packages? If I tried to guess the difference between this an qhull_internal, I'd guess that it's something about when the package is only being used by libraries with internal = True, but also the onl;y user of @qhull_internal explicitly marks it as an implementation dependency.

Reviewed 3 of 4 files at r2, all commit messages.
Reviewable status: LGTM missing from assignee sammy-tri(platform) (waiting on @jwnimmer-tri)

[sammy-tri]

Reviewed 17 of 20 files at r1, 1 of 4 files at r2.
Reviewable status: LGTM missing from assignee sammy-tri(platform) (waiting on @jwnimmer-tri)

[jwnimmer-tri]

Is there a guideline for when we should be using cc_library vs cc_library_vendored for _internal packages?

It's a good question. In a PR soon, I do plan to update drake/tools/workspace/README with more prescriptive advice.

The simple answer in terms of this PR is that #17230 will add vendoring for all three of these. It just ended up being too much work to do the renames, deprecation, and vendoring all in a single PR, so I carved this one out first.

More broadly, it's a one-way implication: anything that's vendored should be marked _internal, but it's OK to have internal repositories that don't use vendoring. For example, @dm_control is just a bunch of model files used for our unit testing. I don't want that to be part of our Stable API policy, so I plan to rename it to @dm_control_internal, but it won't use C or C++ vendoring.

[sammy-tri]

I'll let you race #17322 for who gets the merge commit.

Reviewable status: complete! all discussions resolved, LGTM from assignees rpoyner-tri(platform),sammy-tri(platform) (waiting on @jwnimmer-tri)

[sammy-tri]

err, merge conflict

Reviewable status: complete! all discussions resolved, LGTM from assignees rpoyner-tri(platform),sammy-tri(platform) (waiting on @jwnimmer-tri)

[jwnimmer-tri]

Hmm, that one already needs a rebase anyway, so I'll just go first.