Initial support for dict data structure

[czgdp1807]

Closes #964

Following is the plan,

1. Represent dict with the help of a struct in LLVM. Maintain original key-value pairs for the purpose of collision handling and in case a collision happens then distinguishing between update and insert operation. We need original key-value pairs anyways for all kinds of collision handling strategy.
2. If collision happens while insertion then do linear probing (simple as well as cache efficient).
3. Resizing strategy - All-at-once resizing strategy. Will happen if load factor touches a threshold value. Simpler than lazy resizing in which don't copy all the older key-value pairs into new array but instead only when they are accessed. Its a bit complicated to implement so I will do it in future.

TODOs after this PR - #983 (comment)

[czgdp1807]

@certik This is ready for review. I have mentioned my TODOs after this PR in #983 (comment). You can review each commit individually if you want. Let me know if anything needs a change here.

[certik]

I reviewed every commit, everything looks great.

My only possible question is if the CPython version of the test takes a long time, if so, we should reduce the number of loop iterations in the test.

That can be adjusted later.

So +1 to merge.

Great job!

[certik]

@czgdp1807 is this ordered or unordered dictionary?

[czgdp1807]

I think this is unordered dictionary (because hash maps are unordered in nature). For ordered dictionary we will require an implementation similar to std::map.

Though you can make ordered dictionary out of unordered ones by subclassing and tracking the insertion order of keys. I would keep both ordered and unordered ones as one has some advantages over the other.

[certik]

Here is another way to implement OrderedDict: https://github.com/Aqcurate/OrderedDict#ordered-dictionary-implementation