Suggestion: add UUID library support and an api to generate sha1 digest

[loloicci]

This PR suggests adding UUID library support to package/std.
UUID is useful for managing something in gaming contracts or collection contracts, especially corporate with external servers or services.

This UUID generation uses UUID v5 for deterministic generation and the seed message for sha1 is concatenated bytes of contract address, block height, and an incremental number saved in the contract storage.

UUID v5 uses sha1 internally, and this PR suggests adding an API to calculate sha1 digests.
This API takes a little shorter time and a little cheaper gas to generate a UUID than calculating a digest in WASM native operators.
If the message size gets longer, it gets much faster and takes much cheaper gas than calculating with WASM native.

If this suggestion looks good (even if only the sha1 part), I will modify the gas cost after taking a benchmark with circle CI. (It looks like it is not usable circle ci bench workflow in my GitHub repo)

Only the sha1 part is merged, I will publish the uuid feature in my repository.

[loloicci]

CI fails because of adding a new API.

[aumetra]

Thanks for the PR, but after discussing it internally a bit, we think that we don't want to add hash functions to the API interface.
Reasons are listed here in a similar issue.

The points essentially boil down to:

1. there are a lot of hash functions, adding one kinda opens the floodgates if you get what I mean
2. hash functions are generally rather quick and therefore gas efficient
3. it would add maintainance burden for us, especially since your use-case of SHA-1 for UUID generation is a little more exotic.

Also WASM code execution is rather quick, so the need to add native functions, especially for digests such as SHA-1, isn't as pressing as with other VMs.

---

As a suggestion for your use-case, if the gas cost for SHA-1 is too high, you could use RNGs such as LCG, WyRand, Mersenne Twister, etc. to stretch an input to the length you need.
Since they do not attempt to be cryptographically secure in any way, you might achieve higher throughput (and therefore lower gas costs).

[loloicci]

@aumetra Thank you for considering and kindly replying. I understand that you will not add hash functions and I agree with the reason.

I close this issue. Thank you!