Support 'expected_num_objects' parameter when creating pool for pg folder splitting

This patch adds a new parameter for pool creation named 'expected_num_objects', to give user a choice to specify the number of objects he/she would like to put into the pool. This information is used to pre-hash PG's namespace by creating a certain number of folders, so as to avoid run-time folder splitting which could saturate disk I/O.

Testing - test against various combinations of PG number and splittings.

Issue - as we add two new fields to coll_t struct, and given its encode/decode logic, when we bump up the version number, it could break old version software. This would request to upgrade all nodes before creating new pool.

Todo - doc the behavior.

Signed-off-by: Guang Yang (yguang@yahoo-inc.com)
One difference between this property and others is that we (properly) should not take any action once the pool starts taking data, which means it only takes effect at the pool creation time. (Letting user dynamically adjust this value might bring confusion if we don't take any action, and if we (like splitting), it can bring other troubles which is not covered by the algorithm implemented by this patch).
Given the above reasons, I also made it configurable right at the pool creation time, which makes it serve one purpose as do pre-splitting at the very beginning.
Does that sound reasonable?