feat: added extra basic nested object support

[Alex-Werner]

Issue being fixed or implemented

At current state, it is not possible to push documents containing anything else that string or number (therefore exit any object or array).
This PR allow us to, discarding any indexes, at least get us the data in the document when saved and prevent any error being thrown at us.
As such, finding on a nested object is not possible at current point. We would have many incremental way to implements this, one naive being just to take not of existance of the field and traverse the whole identifiers set containing such property (and then traverse object to find data).

What was done

• feat: added basic nested object support
• fix: added some additional verification on returned data
• test: added remove to standard benchmark
• test: added insert / find on nested object

How Has This Been Tested?

We added a new e2e test that test the ability to push such document.

Notes :

 SBTree - Performance - Standard Benchmark within test 
Will process 5000 elements
Finished writeOp in 179.025662 ms [27928.95691121645] ops
Finished getOp in 57.265078 ms [87313.24874821614] ops
Finished findOp in 1218.748882 ms [4102.567865986358] ops
Finished removeOp in 229.210709 ms [21813.98950255854] ops
    ✓ should be fast (1704ms)
======== SBTree 2.1.0 - Benchmark from mocha
= Write : 27928.95691121645 op/s [5000]
= Get : 87313.24874821614 op/s [5000]
= Find : 4102.567865986358 op/s [5000]
= Remove : 21813.98950255854 op/s [5000]
= ======== Summary
= Total : 20000 operations
= Duration : 1.684250331 s
= Avg : 35289.69075699437 op/s
    ✓ should display result
  SBTree - Performance - Extended Benchmark within test 
Will process 5000 elements
Finished writeOp in 93.075982 ms [53719.55140908425] ops
Finished negFindOp in 19342.125507 ms [49.11559485311946] ops
Finished gtFindOp in 15894.505307 ms [122.68390631454335] ops
Finished gteFindOp in 15133.572913 ms [125.5486731998276] ops
Finished ltFindOp in 14660.703321 ms [122.77719292100255] ops
Finished lteFindOp in 15584.713192 ms [121.91433853112645] ops
Finished inFindOp in 1029.258414 ms [1618.6411277663844] ops
Finished ninFindOp in 36113.346672 ms [36.911561038831216] ops
    ✓ should be fast (117879ms)
======== SBTree 2.1.0 - Extended
= $ne : 49.11559485311946 op/s [950]
= $gt : 122.68390631454335 op/s [1950]
= $gte : 125.5486731998276 op/s [1900]
= $lt : 122.77719292100255 op/s [1800]
= $lte : 121.91433853112645 op/s [1900]
= $in : 1618.6411277663844 op/s [1666]
= $nin : 36.911561038831216 op/s [1333]
= ======== Summary
= Total : 16499 operations
= Duration : 117.85130130799999 s
= Avg : 139.99845412720967 op/s
    ✓ should display result
  SBTree - Performance - Multi-Trees (index/field) benchmark within test 
Will process 10000 elements
Finished writeOp in 705.570184 ms [14172.934495769452] ops
Finished getOp in 138.067018 ms [72428.59406147238] ops
Finished findOp in 7041.613041 ms [1420.1291581594594] ops
    ✓ should be fast (7970ms)
======== SBTree 2.1.0 - Multi-tree Benchmark from mocha
= Write : 14172.934495769452 op/s [10000]
= Get : 72428.59406147238 op/s [10000]
= Find : 1420.1291581594594 op/s [10000]
= Total : 30000 operations
= Duration : 7.885250243 s
= Avg : 29340.552571800432 op/s

We lost a lot in performance here.