Allow duplicate marker type on a portal

[bgillock]

Fixes #319 by removing checks for existing marker of same type in type select list and when adding a marker.

[le-jeu]

Other related parts:

Wasabee-IITC/src/code/dialogs/markerChangeDialog.js

Lines 38 to 45 in bd3020f

	const markers = operation.getPortalMarkers(portal);
	for (const k of WasabeeMarker.markerTypes) {
	const o = L.DomUtil.create("option", null, this._type);
	o.value = k;
	o.textContent = wX(k);
	if (markers.has(k) && k != this.options.marker.type) o.disabled = true;
	}
	this._type.value = this.options.marker.type;

This function is bound to disappear

Wasabee-IITC/src/code/model/operation.ts

Lines 381 to 390 in bd3020f

	getPortalMarkers(portal: WasabeePortal) {
	const markers = new Map<string, WasabeeMarker>();
	if (!portal) return markers;
	for (const m of this.markers) {
	if (m.portalId == portal.id) {
	markers.set(m.type, m);
	}
	}
	return markers;
	}

But that needs work in the applyChanges method

[bgillock]

We can keep getPortalMarkers if we use the m.ID as the key instead of the type. Then make the appropriate changes in applyChanges.

[le-jeu]

that won't be really useful for the applyChanges function, getPortalMakers is there for two reasons:

• support old OP (will be removed), since those OP have only one marker type per portal, it's fine to use current code
• avoid marker edit leading to duplicate markers with same type, this can be removed safely (summary.edition.duplicate)

[bgillock]

With your help, I think I addressed all of the places where a unique marker type was assumed and enforced.

[le-jeu]

No, if you change getPortalMakers you need to udate every uses. But this function can be keep as it was, since it's valid where it's used in applyChanges (1.).
It's just that the mechanism that removes duplicates marker due to marker edit can be removed (2.)