Split ElementPath display away from the ElementHeader component

When we redesigned the navigation header, I had first started a pretty large refactoring that should have made the ElementHeader component much, much simpler. This refactoring had included splitting the ListElementNeighbors-based display away from the ElementHeader: the header component is dedicated to… just displaying a header, which is already quite complex with all the dropdowns, modals, etc., and a new NeighborBreadcrumb component handles display 1 (one) ElementPath at once. This moves all the complicated logic to handle the previous/next buttons away from the already large header component.

Since that refactoring went nowhere, it was intended to be split into two MRs: one to make creating headers easier in general, which got merged, and one to clean up the ElementHeader, which never happened.

During a coffee break while he was working on #1001 (closed), @vrigal reminded me of the complexity of the ElementHeader component, and I also noticed it again while reviewing !1352 (merged). The neighbors display is quite complex and has computed properties, data, etc. with pretty poor names, and is mixed in with the rest of the component. This is a general issue of the Options API that Vue 3's Composition API tries to solve, but rewriting the ElementHeader in the composition API now would be a big mess. We could go back to the original idea of a NeighborBreadcrumb.vue component, which displays just one path.