Ensure that block sequences for delete are returned as an ordered set

This commit addresses an issue where the use of delete concurrency for
removal of the blocks of a single object can cause a
riak_cs_delete_fsm worker process to deadlock and prevent the entire
Riak CS garbage collection from making progress. This bug only
manifests for objects that were uploaded using multipart upload.

The problem rests on the fact that the delete_blocks_remaining field
of the object manifest is treated as an ordered set except when that
set is initially determined for a manifest that contains metadata
indicating it was a multipart upload.

The reason this is an issue and that riak_cs_delete_fsm processes can
persist indefinitely is that the ordsets:del_element call is used to
remove elements of the delete_blocks_remaining set as the delete
workers (whose count is controlled by delete_concurrency) respond that
their assigned blocks have been deleted. If a call to
ordsets:del_element is made with an element that does not exist in the
set or more importantly in this case is made on an unordered set where
the element for deletion sorts less than any key ahead of it in the
the set, the return value is identical to the input set. This can come
into play when you have delete_concurrency greater than 1 and a block
delete worker, call it worker A, assigned to delete a block identified
by {UUID, BlockNumber} return a response to the riak_cs_delete_fsm
process before another delete worker, worker B, whose assigned {UUID,
BlockNumber} pair sorts greater than that of worker A, but appears
before the pair of worker A int the set. More concisely, if the block
assigned to worker A sorts less than that assigned to worker B, but
appears after the block assigned to worker B in the
delete_blocks_remaining set in the manifest and worker A responds
before worker B, then the entry for worker A will not be removed from
the delete_blocks_remaining set. Since the delete fsm relies on
delete_blocks_remaining being empty as a termination condition, the
process will hang forever and GC stalls out.

This commit resolves the issue by ensuring that
riak_cs_lfs_utils:block_sequences_for_manifest/1 only returns an
ordered set regardless of the input manifest.

Additionally this commit also adds some type specs to other key
functions in the riak_cs_lfs_utils module and refactors a code block
in riak_cs_delete_fsm:blocks_to_delete_from_manifest to not export
variables from within a case statement.
Add an eqc to test riak_cs issue 949.
Optimize list appending when establishing manifest block sequences
Merge pull request #949 from basho/bugfix/delete-fsm-stall

GC may stall due to  riak_cs_delete_fsm deadlock

Reviewed-by: bowrocker