Add valkeyCreate() and valkeyGetKey() functions

[zuiderkwast]

@SoftlyRaining PTAL

This is a first draft of the robj hack.

There's a lot of duplicated code with createEmbeddedStringObject, but it's a PoC.

The EMBSTR is compact, but other robj are created with an expire field set to -1 (meaning no expire) and an embedded key pointer set to NULL.

[codecov]

Codecov Report

Attention: Patch coverage is 28.98551% with 49 lines in your changes missing coverage. Please review.

Project coverage is 69.83%. Comparing base (69773b1) to head (ff18524).

Files with missing lines	Patch %	Lines
src/object.c	26.86%	49 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           hashtab    #1020      +/-   ##
===========================================
- Coverage    69.88%   69.83%   -0.06%     
===========================================
  Files          115      115              
  Lines        62252    62319      +67     
===========================================
+ Hits         43503    43518      +15     
- Misses       18749    18801      +52     

Files with missing lines	Coverage Δ
src/sds.c	86.08% <100.00%> (ø)
src/server.h	100.00% <ø> (ø)
src/object.c	75.13% <26.86%> (-3.53%)	⬇️

... and 15 files with indirect coverage changes

[ranshid]

@zuiderkwast / @SoftlyRaining Sorry for crashing into your party :)

I wanted to share that I was thinking of embedding the TTL inside the sds instead of robj.
This is mainly in order to serve a solution for #640 and also fit as general infra for TTL rethinking.
I think that since general items are usually sds we can benefit from keeping an optional TTL embedded inside sds.
Not to dive into too many details we do have 5 spare bits in sds flags so we can use 1 in order to indicate an sds has a TTL.
This way we can make sure a TTL is allocated as part of the sds.
I am working to write up a suggestion but maybe we can sync in order to prevent diverging suggestions about where TTL will be placed?