Simplify ListElementNeighbors

!2038 (merged) was focused on better performance on ListElementNeighbors while maintaining compatibility with the existing serializers, but the existing serializer is responsible for a whole lot of trouble in the frontend. And since the frontend is the sole consumer of this API, we can refactor it easily.

• We can rename position to ordering, since we want to return the raw ordering and not a ROW_NUMBER(). This will make it easier to understand that the ordering is the actual ordering and not a different concept.

• We can switch from building three different objects, which then have to be re-combined by the frontend to detect which elements are the previous and next ones, into a single object with a previous and a next attribute, which also simplifies the backend implementation. This may make it possible to actually navigate between top-level elements despite them not having any valid orderings.

• We can remove the pagination. Knowing how many neighbors will be returned to allow pagination (something like the hacks we did back in the Elasticsearch era) is not possible without computing all the neighbors already, so we're stuck. We can remove it, and this means the frontend can now handle more than 6 parents at once (at the seventh parent, if you have a previous and a next element for each parent, then you get 21 elements which goes beyond the first page of results). This issue was noticed in teklia/requests#1.

So the response serializer could look like this instead:

[
  {
    "path": [
      {
        "id": "...",
        "name": "Top s3kr3t",
        "type": "folder"
      },
      {
        "id": "...",
        "name": "Plans for world domination",
        "type": "folder"
      }
    ],
    "ordering": 42,
    "previous": {
      "id": "...",
      "name": "Vore the rich",
      "type": "plan"
    }, // or null if there's no previous element
    "next": {
      "id": "...",
      "name": "All your base are belong to us",
      "type": "plan"
    } // or null if there's no next element
  },
  {
    // Another path...
  }
]

When updating the frontend, it might be a good time to do frontend#1102 (closed) instead of trying to update the existing complex header component. This would make the Actions and Display menu usable immediately even when the neighbors are still loading, instead of hiding everything in the header with a Loading… state.

(Follow-up from https://gitlab.com/teklia/arkindex/backend/-/merge_requests/2038#note_1461517584)