This PR enables a 0(1) bidirectional mapping meosType → PostgreSQL Oid and Oid → meosType.

There is already a 0(1) mapping from meosType -> Oid provided by the function

Oid meostype_oid(meosType type)

which is implemented as an array of size NO_MEOS_TYPES (currently 63). This array allows us to obtain the Oid corresponding to a meosType by accessing an element of the array as follows

Oid result = MOBILITYDB_CONSTANTS->meostype_oid[type]

The mapping from Oid -> meosType provided by the function

meosType oid_meostype(Oid typid)

is now implemented as a hash table using the include file simplehash.h. This hash table allows us to obtain the meosType corresponding to an Oid by accessing using a hash-table lookup as follows

oid_meostype_entry *entry = oid_meostype_lookup(
    MOBILITYDB_CONSTANTS->oid_meostype, typid);
  if (! entry)
    return T_UNKNOWN;
  else
    return entry->type;

instead of the previous solution which consists on the following loop

  for (int i = 0; i < NO_MEOS_TYPES; i++)
  {
    if (MOBILITYDB_CONSTANTS->meostype_oid[i] == typid)
      return i;
  }

The reason for this solution is that the look up of a meosType from an Oid is needed at every single access of a value of a MEOS template type, i.e., set, span, spanset, and temporal types, as in the following example

Datum
Temporal_in(PG_FUNCTION_ARGS)
{
  const char *input = PG_GETARG_CSTRING(0);
  Oid temptypid = PG_GETARG_OID(1);
  Temporal *result = temporal_in(input, oid_meostype(temptypid));
  [...]
  PG_RETURN_TEMPORAL_P(result);
}

Therefore, the heavy usage of this function motivates using a hash table.

An alternative solution is to have an Oid-indexed array with 2^32 = 65536 entries since the Oid type is defined as follows

typedef unsigned int Oid;

Although this solution is simpler algorithmically, only NO_MEOS_TYPES out of the 65536 slots are used and thus it wastes memory for unused slots.