Separate out underlying custom canonize primitive

[dlongley]

The hmacIdCanonize primitive allows for a labelMap to be passed as an alternative to an hmac -- and it internally uses a custom canonize function. We should expose the custom canonize function and have it take an asynchronous label mapping function.

We could then build a simple helper canonize primitive that just takes a labelMap that is used instead of the hmacIdCanonize one -- and that can be reused with any labelMap.

We should also ensure that the approach passes the normalized dataset (or minimally the canonicalIdMap) to the label mapping function such that a function could be written that considers the total number of blank nodes. Such a function would be useful to SD schemes that want to make HMAC'd bnode labels map to a smaller namespace (rather than using the whole digest). An example would be:

// closure has an HMAC, can be auto-provided by or passed
// to another primitive function that does this common behavior
const hmac = createHmac();
let labelMap;

async function labelMapper({label, canonicalIdMap}) {
  // init labelMap if not initialized yet
  if(!labelMap) {
    // hmac all labels in `canonicalIdMap`
    const hmacs = await Promise.all([
      [...canonicalIdMap.values()].map(
        label => ({label, signature: await hmac.sign(label)}))
    ]);
    // sort based on signature...
    // deal with base64url encoding either before or after
    // sort considering tradeoffs of implementation ease
    // vs. efficiency
    hmacs.sort(comparator);
    // fill `labelMap` in order
    labelMap = new Map();
    hmacs.forEach(({label}, i) => labelMap.set(label, `b${i}`));    
  }
  return labelMap.get(label);
}

[dlongley]

See #9 for how to better slot the above example in.