Item page entities changes/refactoring

Conflicts:
	src/app/+item-page/simple/item-types/shared/item-relationships-utils.ts
	src/app/+item-page/simple/item-types/shared/item.component.spec.ts
	src/app/+item-page/simple/item-types/shared/item.component.ts
	src/app/+item-page/simple/metadata-representation-list/metadata-representation-list.component.spec.ts

Name variants on item pages

Update webdriver-manager library

Correct baseUrl in local.cfg used by e2e tests

Collections pages: add collection header and footer to all "browse by..." views

Item-Collection mapper

Because we're working with ngModel, we're no longer getting a generic JS event in the onSelectChange, but simply the id of the selected option. I use that Id to find the option in the allOptions array that matches, and then use the data inside that matching option to navigate to the correct page.

That currentOptionId$ observable is then used in the template to set the ngModel for the select, which, as mentioned above, should have been enough to select the correct option, but as it wasn't I also use it to set the selected attribute on the options

Next in order to know what page we're on, I use the route.url observable angular provides us that contains the current url, pipe that through a filter to ensure it has a value for the map below, which will just get the last part of the current url, so the community or collection id, or the type of the browse page.

I created a list in the component that contains all the possible values a button or an option in the select can have, that way we can get rid of those *ngIfs in the template, and render everything with an *ngFor
Instead of putting all the data needed to select an option and to redirect to the correct option in the template, I created an interface to represent all the info we need: ComColPageNavOption
During ngOnInit, I first take the browseBy types in the config, and perform a map operation on them, that basically means, turn every element of this array in to something else using the function inside the map operator.
So inside the map function I each BrowseByTypeConfig object in to a ComColPageNavOption object
Afterwards I check whether we're dealing with a collection or a community, and in each case I create a ComColPageNavOption object, and add it to the front of the allOptions array
...this.allOptions means enumerate everything that's currently in the allOptions array, so I put my new object first, then enumerate everything that was already there, and assign the result again to this.allOptions

Conflicts:
	src/app/core/data/relationship.service.spec.ts

[DS-4346] V2: create docker compose files in code base

Small bug-fix due to changes to relationship-type

Rename relationship type properties