first try at alarm clock

just added a static reference to the slept thread and its timeout.
thread is blocked, then interrupt handler checks timeout and unblocks.

this won't keep track of multiple slept threads.
also maybe screws with interrupt levels improperly in timer_sleetp ()...
.gitignore
Real attempt at alarm_clock

added a list of sleeping threads.
added the sleep_til time inside the thread struct,
so that timer_interrupt knows how long to wait.
loop through all sleeping threads that need to be woken up
in order (using order of sleep_list) in timer_interrupt
alarm clock fixes

safety check for empty sleep_list in timer_interrupt (it's gonna happen all the time)
some spelling issues and other stuff
some random additions for priority scheduling

in thread_tick, it loops through ready threads checking for higher priority threads to run

in synch, lock_acquire has been modified to include donation current thread priority to the lock holder
more in depth lock stuff

lock actually keeps track of old priority, so that it restores it when the lock is released.

still some potential issues here, but extended donation will happen if its all on the same lock and if its in the right order.

or will it? check that.  probably have to mess with how semaphore waiters are handled?
various fixes

just to make it build... all pointer crap and typos
framework for mlfqs

checking the thread_mlfqs bool (set by mlfqs flag at command line)
synch.c skips donation
thread.c has alternate versions of the ready_list
thread.c also has to update priorities, but I'll do that next
fixed some typos

as usual, the build always uncovers issues.  typos, for loop standard stuff, etc.
proper alarm clock functioning?

test
Merge branch 'alarm_clock' into priority
some preemption logic that actually makes sense

what was I thinking?
changed some things

some odd anomalies in original code...

now ready_list is always sorted in increasing order by priority.  schedule pulls threads off the back.  yield, unblock, etc. all put the thread in sorted order by priority.  thread_tick only needs to check if the back of the list (highest priority) is higher than current priority.  it also still does the round_robin right now (max CPU time even if highest priority)
possible fix

list_back needs non-empty list.  preemption only makes sense if the ready_list isn't empty
more possible fixes
some more possible fixes for priority donation

actually keeping the ready list sorted and yielding when we need to, so the scheduler can keep up and preempt immediately as desired.
not positive that will actually happen ...
pointers ...
harsher scheduling enforcing
playing around ...