[JENKINS-71148] avoid empty tooltips

[mawinter69]

when the tooltip or html tooltip attribute is empty or whitespace only it is avoided that tippy is invoked at all which would otherwise just display a small but empty element.

Before:

After:

See JENKINS-71148.
Solves also JENKINS-72743 but in a generic way that also avoids empty tooltips in other places.
see also #8972

Testing done

Proposed changelog entries

• JENKINS-711478, do not show empty tooltips

Proposed upgrade guidelines

N/A

### Submitter checklist
- [ ] The Jira issue, if it exists, is well-described.
- [ ] The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see [examples](https://github.com/jenkins-infra/jenkins.io/blob/master/content/_data/changelogs/weekly.yml)). Fill in the **Proposed upgrade guidelines** section only if there are breaking changes or changes that may require extra steps from users during upgrade.
- [ ] There is automated testing or an explanation as to why this change has no tests.
- [ ] New public classes, fields, and methods are annotated with `@Restricted` or have `@since TODO` Javadocs, as appropriate.
- [ ] New deprecations are annotated with `@Deprecated(since = "TODO")` or `@Deprecated(forRemoval = true, since = "TODO")`, if applicable.
- [ ] New or substantially changed JavaScript is not defined inline and does not call `eval` to ease future introduction of Content Security Policy (CSP) directives (see [documentation](https://www.jenkins.io/doc/developer/security/csp/)).
- [ ] For dependency updates, there are links to external changelogs and, if possible, full differentials.
- [ ] For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@mention

Before the changes are marked as ready-for-merge:

### Maintainer checklist
- [ ] There are at least two (2) approvals for the pull request and no outstanding requests for change.
- [ ] Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
- [ ] Changelog entries in the pull request title and/or **Proposed changelog entries** are accurate, human-readable, and in the imperative mood.
- [ ] Proper changelog labels are set so that the changelog can be generated automatically.
- [ ] If the change needs additional upgrade steps from users, the `upgrade-guide-needed` label is set and there is a **Proposed upgrade guidelines** section in the pull request title (see [example](https://github.com/jenkinsci/jenkins/pull/4387)).
- [ ] If it would make sense to backport the change to LTS, a Jira issue must exist, be a _Bug_ or _Improvement_, and be labeled as `lts-candidate` to be considered (see [query](https://issues.jenkins.io/issues/?filter=12146)).

[daniel-beck]

Are you doing null checks deliberately not with === etc? (Curiosity more than request for change)

[daniel-beck]

Seems to work well, thanks 👍

[NotMyFault]

/label ready-for-merge

---

This PR is now ready for merge. We will merge it after ~24 hours if there is no negative feedback.
Please see the merge process documentation for more information about the merge process.
Thanks!

[daniel-beck]

NotMyFault added the regression-fix label

IMO not a regression. The tooltip that #8972 addresses has been empty since it was added in 2.220, with the problem existing probably far longer.

If you disagree, what release introduced the regression?

[mawinter69]

I think it is a regression introduced with #6408 when YUI tooltips were replaced by tippy

[daniel-beck]

That was merged in 2.380. Note the screenshot in my issue that I took in 2.220 (and that's just when that tooltip was added). So at least that specific instance is far older.