Fix memleak on high network activity

net_queue_newentry returned an entry that would be marked to be processed,
which in some cases would be done by the process task before the data
was copied, and thus, the mdupped packet would not be freed.

Solution is to add another state, SCHEDULED, calling the current one RESERVED.
Fix screendump spans; add screenbuf dump.

The url /C will now dump the entire screenbuffer.
On EOL the spans would not be closed, causing very deep nesting confusing
the browser.
paging debugging disable
Fix memleak; mem renames; add mem -ha|-hs.

kernel/mem.s:
	mfree:
		in handle_merge_fa$, the case where the next handle's base
		is shifted back, also increase it's size.

		This is the main change fixing a memleak where handles would
		show a smaller size than they actually occupied in the address
		space.
		Also, this prevented handle merging since the base + size would
		never add up to the next handle, causing memory scattering.

	rename print_handle(s|_2?)$ to mem_print_handle(\1).

	rename ll_update$ to ll_insert_sorted$.

	add mem_print_ll_handles$, which loops through the given linked list.
	This is used to display handles based on address, or size.

	update cmd_mem, add -ha and -hs options to do just that.

	update print_handle_2$ (now mem_print_handle_2$) to calculate
	the handle number based on ebx - [mem_handles].

	add labels handle_ll_(fh|fs|fa) reffering to the handle_(\1)_first,
	and use those where appropriate.

	change -1 checks from 'or eax,eax; js' to cmp -1, jz in most places,
	though it is unlikely that the handle indices (relative to mem_handles)
	will ever become more than 2Gb (i.e., 2Gb / 32 bytes handles).

	add debugging.

	fix the case where calling ll_unlink on an item not part of that list
	would clear the list's first/last.

	also in handle merge called by mfree, set the base of the emtpy handle
	to 0, and call ll_update_right instead of unlink/update(now insert sorted).

	ll_update_left was no different than ll_insert_sorted.

	ll_update right now fixed to at least properly scan forward.

	Both ll_update_left and right call ll_insert_sorted rather than
	ll_insert.

	There is a bug where ll_insert_sorted (called from ll_update_right)
	can cause some local swapping to occur in the fs (size) list, making
	it no longer globally ordered.
	The find handle by size code assumes the list is ordered and simply
	expects ever larger (or equal sized) items, and it is not thrown
	off by encountering a smaller item. Thus this bug has no effect as yet.

kernel/debugger.s:
kernel/net/tcp.s:
kernel/schedule.s:	# comments only
	print_handles$ -> mem_print_handles
	print_handle_$ -> mem_print_handle_$