runtime: factor out bitmap, finalizer code from malloc/mgc

The code in mfinal.go is moved from malloc*.go and mgc*.go
and substantially unchanged.

The code in mbitmap.go is also moved from those files, but
cleaned up so that it can be called from those files (in most cases
the code being moved was not already a standalone function).
I also renamed the constants and wrote comments describing
the format. The result is a significant cleanup and isolation of
the bitmap code, but, roughly speaking, it should be treated
and reviewed as new code.

The other files changed only as much as necessary to support
this code movement.

This CL does NOT change the semantics of the heap or type
bitmaps at all, although there are now some obvious opportunities
to do so in followup CLs.

Change-Id: I41b8d5de87ad1d3cd322709931ab25e659dbb21d
Reviewed-on: https://go-review.googlesource.com/2991
Reviewed-by: Keith Randall <khr@golang.org>

src/runtime/type.go

@@ -22,7 +22,7 @@ type _type struct {
 	// (no indirection), 4 bits per word.
 	// If (kind&KindGCProg)!=0, then gc[1] points to a compiler-generated
 	// read-only GC program; and gc[0] points to BSS space for sparse GC bitmap.
-	// For huge _types (>MaxGCMask), runtime unrolls the program directly into
+	// For huge _types (>maxGCMask), runtime unrolls the program directly into
 	// GC bitmap and gc[0] is not used. For moderately-sized _types, runtime
 	// unrolls the program into gc[0] space on first use. The first byte of gc[0]
 	// (gc[0][0]) contains 'unroll' flag saying whether the program is already