Fixes #1107
Fixes #1157
Fixes #1158

This PR tries to not change how readline worked in the past, while introducing tty rows to the system, this is achieved by refreshing the whole line with all of its rows (by making sure to always start writing from the left of the very first row). Unlike the way NodeJS's refreshLine clear the screen, this will only clear said line, which means we must handle each position change differently and separately; that might be unclean, but it is the best way available to us without having to rewrite the whole thing. I will walk you through each of those changes step by step.

1. Editor.getCursorOffset: This is the way I am using to measure where exactly the cursor is, we could've used ESC[6n instead, or used the NodeJS of manually counting each character width, but both will require a good portion of code while the first requiring a bit of rewrite of how onKey works. This seems to be accurate as long as UTF-8 unicodes are not presented (more about that later). On the other hand, there is no need for NodeJS's way of doing it since Luvit repl does not allow tabs characters in a row entered by the user. Although do note that this makes use of Editor.columns which is NOT updated on resize events, meaning all you need to break this is resizing the terminal; I do plan on implementing this later on.

2. refreshLine's command: Couple required changes were made here, first of them forcing a new line to fix # , making sure the cursor goes to a new line when needed. Second of them is using ESC[0J which is not required but it makes more sense, plus it simplifies handling the deletion of first character of a row.

3. refreshLine's row refreshing: This will basically force the cursor to go up first initial line, to start the rewrite from there. As you can see because of the way we are handling this we will have to handle each case separately, having to handle a row up (moveLeft) and a row down (moveRight).

4. Editor.insertAbove: Since the user might trigger this when they are at first row while having more rows, we need to handle this a bit differently than used to. Neither this nor previous implementation handled more than a single row insertion.

5. Editor.insert: Making sure the cursor is always visible, trigger a refreshLine when a new row is required.

6. The rest of small stdout:write (ones as in here) were required to handle each case separately. Maybe there is a cleaner way of doing it?

7. readline's finish: Make sure results are displayed right when the user hit enter at a row above the last row.

8. Editor.pervRow: Required to track the movement of the cursor, this is the same as NodeJS's implementation.