legacy-free grid container

[Havoc Pennington <hp pobox com>]

With
https://bugzilla.gnome.org/show_bug.cgi?id=628828
and
https://bugzilla.gnome.org/show_bug.cgi?id=628902

Box and Table are pretty much all messed-up. They have a bunch of
redundant flags to specify, and their redundant fill flag is a problem
because it has the wrong default (must always be true to make the
widget flags work).

Rather than churn up Box and Table in-place, maybe it would be nicer
to create a legacy-free new GtkGrid.

The basic idea of GtkGrid is:

* it just puts things in rows and columns, and implements homogeneity;
expand, fill, padding are now all in Widget
* it is an infinite grid, not a fixed size at construct time like
GtkTable. so you don't have to keep construct size in sync with what
you add. It auto-resizes to hold stuff.
* the coordinate system goes into negative numbers, so you can add
things on either side of the axes
* its "default" mode if you just container_add() is like a box, in
that it just keeps appending children to the axis. they are then in a
single-row or column table. this lets it replace Box.
* but you can also do an add_at(grid, child, x, y, cells_wide,
cells_high) (note, coords then WxH in cells, rather than annoying
"attach points" where you have to change both numbers to move)
* you could also do add_by(grid, existing_child, child,
side_of_existing_child, cells_wide, cells_high) which lets you build
things up relatively. this is nice because if you want a stack of
stuff above the foobar, and you insert something before the foobar,
you don't have to go and redo all your coordinates
* have separate "h" and "v" homogeneous flags to force all rows or all
columns to be the same height
* have separate "h" and "v" spacing which would be the same between
all rows or all columns
* minor thing: kill SHRINK mode in table, it's broken (esp. in a world
with min size separate from natural)
* an issue: the naming of the cell-based access (x,y) is a mess if you
allow it to be GtkOrientable like box. but if you require an
add_on_axis(orientation, child) then it's not as convenient as box.

Anyway something like that. It's just a box if you create and
container_add(), but it can become a table if you just start packing
things off the main axis (no more "box regret" - "I wish I'd used a
table now that I'm halfway into this!"). And it lacks the redundant
padding, expand, fill confusion when mixed with the new patches.

Probably there are better plans but that's the one I thought of.

Havoc