[JENKINS-70169] Add missing breadcrumb items in resources/jenkins

[lemeurherve]

Extract from #7457

Follow-up of #6912

Initially fixing JENKINS-70169, I've included every missing breadcrumb items I've found by searching for "sidepanel.jelly" in jelly files.

Notes:

• I've added <!-- no need for breadcrumb here --> as comment in views where adding a breadcrumb item wasn't necessary, let me know if it's preferable to omit them.
  As noticed in the review comments, the presence of f:breadcrumb-config-outline tag is enough to indicate page not needing an additional breadcrumb.

• This doesn't fix missing breadcrumb depending on plugin (ex: Add missing breadcrumbs to job configuration cloudbees-folder-plugin#278)

Testing done

Built and ran Jenkins locally, going on modified pages to check the change.

There is no additional automatic test added for these breadcrumb items.

http://localhost:8080/jenkins/manage/computer/(built-in)/configure:

http://localhost:8080/jenkins/manage/restart/:

http://localhost:8080/jenkins/manage/safeRestart/:

http://localhost:8080/jenkins/fingerprintCheck:

http://localhost:8080/jenkins/legend:

http://localhost:8080/jenkins/newView:

http://localhost:8080/jenkins/projectRelationship:

(no idea where to find the legacyApiTokenAdministrativeMonitor one...)

Proposed changelog entries

• Entry 1: Add missing breadcrumb items in resources/jenkins
• […]

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).
  • 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).
• 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

Maintainer checklist

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

• 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).
• 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).

[NotMyFault]

Breadcrumbs for last views have been restored in de35224, but I would still want to go ahead with this series of PRs, and add breadcrumbs to views, which don't have any yet.

[timja]

/label ready-for-merge

---

This PR is now ready for merge, after ~24 hours, we will merge it if there's no negative feedback.

Thanks!