Migration to ViewBinding

Issue Fix

Fixes #22 (closed)

Description

Too sleeepy to write it right now 💤

• ViewBinding over Kotlin Synthetics and findViewById().
• Doing so is a better way of referencing and using the views, while using Kotlin Synthetics we can get a runtime error in the application resulting in crash. That RTE may arise because of two different views having same Id(which is very possible) in two totally different layouts, also since these Kotlin Synthetics don't come with compile time checks, therefore runtime error is inevitable in the cases like the one mentioned.
• findViewById() has been removed because it increases memory consumption by the application, as it searches the entire view heirarchy of the layout visible on the screen, in the runtime. Although it does not show that noticeable lag in the application initially, but it becomes a big pita as the application grows.
• ViewBinding removes all these concerns and generates java classes corresponding to the layout files and uses them for referencing the views, so here do not exist any conflicting declarations like for the case mentioned above for Kotlin Synthetics, because each view is referenced to its corresponding binding class, which is auto-generated from the layout file. Also no runtime errors, as everything gets checked in the compile-time itself. yeah those errors are inevitable if you don't inflate a layout in the application screen and reference them :P

---

• TL;DR Kotlin Synthetics have been deprecated(since they cause RTEs) and using findViewById() is a crime

Alternative(s) considered

• Introduction of ViewBinding
• Removal of findViewById()
• Removal of Kotlin Android Extensions aka Kotlin Synthetic Bindings

Type

Choose one: Code health

Screenshots (if applicable)

NA

PS: This branch is based off s-ayush2903/android/#23-KotlinDSL-instead-Groovy so that it doesn't have to face merge conflicts and no need to rebase again after the related MR(!36 (closed)) is merged.