Separate the btree maximum key/value sizes from the underlying page size

Separate the btree maximum key/value sizes from the underlying page size, reference #1282.

It's not worse (at least for most access patterns), but I can't imagine the workload.

When I was trying to wrap my head around this change, the only dividing line I came up with is scan vs. random search.

If you're doing a random search: huge items appearing as part of the tree are bad, because they eat the cache for no purpose. So, there's a page that has 10 items, one of which is 50MB, and a random search for any of those items results in a 50MB read. We might be able to make that tolerable by ensuring that huge items get their own page, absent all surrounding data -- I didn't do that, I specifically put small stuff logically near the huge stuff on the same page as the huge stuff. If changes huge stuff to have its own page, the only bad thing about huge items is they eat an entry in their parent page.

If you're doing a table scan, you might as well just read the huge item in one read instead of doing two I/Os (the second to get the overflow value), it's faster to stuff everything in the tree if you're doing table scans.

Am I missing something?

There's an argument to be made here that we should get rid of overflow items entirely.