Refactor Core @Context terms to https based namespace and use fragments for term URIs

Background:

We plan to use "https://uri.etsi.org/ngsi-ld/v1" as a shortcut URI to redirect (through content negotiation) to https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld (already asked to ETSI)

If, for consistency, we migrate our Core @context terms to https schema then our terms will look like

"Property": "https://uri.etsi.org/ngsi-ld/Property" or whatever.

So for some people it could be misleading to use "https://uri.etsi.org/ngsi-ld/v1" as it could seem that a v1 @context term would exist when it doesn't. Also, imagine the, unlikely, event that some introduces a new API term named v1. So it would be good, consistency-wise, to use a more concrete path for core @context terms. And also, using URI fragments, could be a good idea as W3C WoT is doing, see https://github.com/w3c/wot-thing-description/blob/master/context/td-context.jsonld

A proposed new path for our @context terms would be

"https:/uri.etsi.org/ngsi-ld/core"

and with URI fragment representation it would look like as follows

"Property": "https://uri.etsi.org/ngsi-ld/core#Property"

with URI paths it would look like as follows

"Property": "https://uri.etsi.org/ngsi-ld/core/Property"

A separate discussion is whether we should declare our Core @context using URI prefixes or not (performance wise).

The different options are summarized below.

Option 1. No prefix and Fragments

"@context" : {
    "Property": "https:/uri.etsi.org/ngsi-ld/core#Property",
    ... 
}

Option 2. Prefix and Fragments

"@context" : {
    "ngsi-ld": "https:/uri.etsi.org/ngsi-ld/core#",
    "Property": "ngsi-ld:Property",
    ... 
}

Option 3. No prefix and regular URI paths (Closest to what currently have)

"@context" : {
    "Property": "https:/uri.etsi.org/ngsi-ld/core/Property",
    ... 
}

Option 4. Prefix and regular URI paths

"@context" : {
    "ngsi-ld": "https:/uri.etsi.org/ngsi-ld/core/"
    "Property": "ngsi-ld:Property",
    ... 
}