Comment 4 for bug 1236102

I was thinking we'd do something similar to what we've done for blocktype categories in "install_blocktype_categories_for_plugin()".

So,

1. We add a "public static function get_gravity()" or maybe "get_sortorder()" to PluginBlocktype, so that each blocktype plugin will override it and define their own sortorder/gravity number

2. At installation or upgrade time, we check that function to find out the blocktype's sortorder. Then we store that value in the database somewhere.

3. Then when we're displaying the block palette on the "edit page" screen, as well as pulling which category each block's in, we also pull its sortorder/gravity. We sort accordingly. In case of a tie, we break the tie with block name. For backwards compatibility with older 3rd party plugins, blocks with no sortorder just come last, sorted by block name.

4. For the core plugins, we space their sortorder out by 100 so that there's plenty of space in between for 3rd party plugins to fit into the sort order.

Third party developers simply add a "get_sortorder()" method to their blocktype plugins, and they'll be inserted into the sortorder accordingly. There is the potential for multiple 3rd party block plugins from separate authors to interfere with each other's ordering. In theory it might be a good idea to provide an admin screen to let admins reorder the blocks, but that might be overkill for something not many would bother to do.