test-hashmap: add test to compare hashmap_free performance

test-hashmap: add test to compare hashmap_free performance

The point here is to compare speed of hashmap_destroy with free and a different
freeing function, to the implementation details of hashmap_clear can be
evaluated.

Results:
current code:

/* test_hashmap_free (slow, 1048576 entries) */
string_hash_ops test took 2.494499s
custom_free_hash_ops test took 2.640449s

string_hash_ops test took 2.287734s
custom_free_hash_ops test took 2.557632s

string_hash_ops test took 2.299791s
custom_free_hash_ops test took 2.586975s

string_hash_ops test took 2.314099s
custom_free_hash_ops test took 2.589327s

string_hash_ops test took 2.319137s
custom_free_hash_ops test took 2.584038s

code with a patch which restores the "fast path" using:
    for (idx = skip_free_buckets(h, 0); idx != IDX_NIL; idx = skip_free_buckets(h, idx + 1))
in the case where both free_key and free_value are either free or NULL:

/* test_hashmap_free (slow, 1048576 entries) */
string_hash_ops test took 2.347013s
custom_free_hash_ops test took 2.585104s

string_hash_ops test took 2.311583s
custom_free_hash_ops test took 2.578388s

string_hash_ops test took 2.283658s
custom_free_hash_ops test took 2.621675s

string_hash_ops test took 2.334675s
custom_free_hash_ops test took 2.601568s

So the test is noisy, but there clearly is no significant difference with the
"fast path" restored. I'm surprised by this, but it shows that the current
"safe" implementation does not cause a performance loss.

When the code is compiled with optimization, those times are significantly
lower (e.g. 1.1s and 1.4s), but again, there is no difference with the "fast
path" restored.

The difference between string_hash_ops and custom_free_hash_ops is the
additional cost of global modification and the extra function call.