Open questions:

• Better function name?
• How much validation do we want to do? I'm doing a few basic range checks on res, base cell, and digits, but do we also want to call isValidCell to ensure the output is valid? The downside would be the additional overhead of the check, and I expect that most users of this function will be creating cells from component data that they already know would produce a valid cell.
  • One potential use case for this function would be to create invalid cells (like deleted subsequences) for us to use in tests elsewhere, so we'd want this function (or maybe an internal-only version) to be able to create such cells. Thus, one option would be to restrict the domains of the inputs for this function to only those that are representable in the H3Index bit representation, even if it results in an invalid cell.
• Errors: we have E_RES_DOMAIN, but the most specific domain error for base cell or digit being out of range is E_DOMAIN. Maybe we should create additional, more specific errors for these two cases.

coverage: 98.944% (+0.01%) from 98.934%
when pulling 3a456d5 on ajfriend:cell_from_components
into 50d4dbe on uber:master.

cc: @zachasme

This would definitely cover my use-case! 👍

Update:

• The function should only be able to create valid H3 cells that pass isValidCell(). All other malformed inputs should raise an error.
• Add a few new H3Error codes for more specific error information: E_BASE_CELL_DOMAIN, E_DIGIT_DOMAIN, E_DELETED_DIGIT