"Porting" to 64-bit building environment

After these couple years, after Rebo's birth,
this infant kernel can not even be built on my new 64-bit linux.

There are files lacked on github, they are brought back from somewhere
local copy. And then, the makefile is modified for the new usage of new
versoion of compiling tool. Some syntax check become more rigorous, so
the source code is modified accordingly.

It builds now, but I do not know whether it runs yet.
Can run now after fixing some build process.

Added volatile in local variables in __readSectors() function so that it
won't be optimized out. (Need to double check this part)

Modify linker script 'link.ld' *secbootinit.s.o to *secbootinit*.o.
Otherwise, 16 bit data was put int 32 bit region and used wrong address.

Former is intended for cmake.

Later should be suitable for both cmake and traditional make.
Added the (not working yet) CMakeLists.txt
CMake can compile secboot.elf now.

Going to make it build secboot.bin.

And then boot.elf, boot.bin, and HD image finally.
Can use cmake to create secboot.elf and boot.elf.

Use make_images/b2.sh to generate hd image.
Enhance and __readSectors() and enlarge...

the range of disk image to load for second stage boot image.
Handle IRQ7, the spurious interrupt.

It is an interrupt accompanying IRQ0 when timer is enabled.

Bochs seems not able to mask this interrupt, so a null handler is
installed for it.

Without this hack, things can not go smoothly.
Stop sending characters in user mode.

The segment selector to screen buffer is of privilege level 0. Using
this selector should yield protection fault.

But Bochs does not trap this fault. This did caused a problem in qemu
and virtual box, but I cannot explain the stack of qemu at entering int
0x0d. The 'return address' in the stack points to a place that is
unlikely to violate protection. It just mov a const into %eax.

But because %ds was always 0x20 when protection fault, it is most
suspicious that the Screen::putchar() is the root cause. And the
phenomenon disappeared after stopping writing to screen buffer in user
mode.

Considering linking i386-stub.c to hOS. Becuase bochs can not send out
serial port content as expected. We might need to debug on qemu or
virtual box. And we are going to debug on a physical machine finally.
Do context switch immediately after unlocking scheduler.
Clarify the bug that enter int 0x0d (GP)

It is because that the 'ds' register was set to 0x20 rather than 0x23.
Then, used under privileged level 0x03.

In spec, this usage is not specified clearly.

Bochs does not do this check.

qemu and virtualbox do this check.

Use 0x23 instead of 0x20 to circumvent this controversy.