Update the README

[ad4rsh2701]

Only After #6 (Create a CONTRIBUTING.md file), you shall touch this issue.

The current README was made in agony, most likely, I do not remember, but we need a better front facing homepage to give much better idea about RiRi.

So, rewrite the README.md, and it should:

• Represent what RiRi actually is
• The roadmap (don't call it roadmap though, we can think of a better name).
• It's expected benefits (I know we can't give benchmarks yet, but giving use case scenarios may help)
• Future of RiRi
• Using RiRi - A theoretical guide as to how RiRi will be used (Good luck with this, may coffee help you).
• Building Riri - Also a theoretical guide (I am so sorry, but you have got to use cmake this time, just use it, skip daily commit goal, if it helps).
• Future expansion: Give notes on what AFTER the basic stuff, client-server, those security stuff (yes, we omitted that, but the entire identity of RiRi is, simple, fast, efficient and secure), give briefing on the variant of E2EEE you are going to use (Fourier series to add complexity).
• And of course, some FAQs to clear confusion.
• Do thank the reader, you aren't getting any anyways.
• Add anything a typical readme DOESN'T have, and also those which a typical readme does have, but better

Have fun, cry, scream, etc.
I know this is the most hated part, but also the most important.

[ad4rsh2701]

Never mind the E2EE part, just mention that security layers, and it should be enough, that thing is already POST POST MVP stuff, so it's alright if we are not explaining that.

And for anyone curious, E2EE involves ellipses, one ellipse though, the plan was to use Fourier series to get multiple ellipses, essentially increasing complication or increasing the domain of the function, which just increases the entire set of values, substantially. This idea came to me in semester 2, during math lecture on Fourier series lol, not sure if it will work though, so it's better if we don't add something we are not 100% sure about in the readme.

[ad4rsh2701]

Hold onto the README, complete the MVP, then release with the README.

Why?

CMAKE will ruin your life, and there's a likely possibility of multiple nuanced changes, that is probably worth adding to the README, regardless, it would be better if the README comes with MVP.

And let's be honest, you'd rather work on #7 than work on README right? So, relax, and complete the MVP and release with the MVP.