Implemented COPY <cstore_table> TO ... feature

COPY <cstore_table> TO ... statement is converted to COPY (select * from <cstore_table>) TO ... format and forwarded to native COPY function of postgresql

A minor bug in drop command is fixed to allow dropping of multiple cstore tables at once.
I think the flow of this function was not easy to understand. Your changes made it easier to understand, but I think we have still room to improve.

For example, when one reads this function, it is not obvious what will happen for the DROP statements. This is because we don't know what is the value of ```commandHandled``` before looking at the implementation of ```CStoreProcessDropCommand```.

My suggestion for this function is introducing a function for "calling the previous utility hook or the standard hook" and remodeling the function as follows:

```C
{
	/* handle "COPY cstore_table ..." statements */
	if (nodeTag(parseTree) == T_CopyStmt)
	{
		CopyStmt *copyStatement = (CopyStmt *) parseTree;
		if (CopyCStoreTableStatement(copyStatement))
		{
			CStoreProcessCopyCommand((CopyStmt *) parseTree, queryString,
								 	 completionTag, &commandHandled);
		}
		else
		{
			CallPreviousProcessUtility(parseTree, queryString, context,
									   paramListInfo, destReceiver, completionTag);
		}
	}
	/* handle "DROP FOREIGN TABLE cstore_table" statements */
	else if (nodeTag(parseTree) == T_DropStmt)
	{
		List *droppedCStoreFilenameList = DroppedCStoreFilenameList(parseTree);

		CallPreviousProcessUtility(parseTree, queryString, context,
								   paramListInfo, destReceiver, completionTag);

		foreach(droppedCStoreFilenameCell, droppedCStoreFilenameList)
		{
			char *droppedCStoreFilename = lfirst(droppedCStoreFilenameCell);
			DeleteCStoreTableFiles(droppedCStoreFilename);
		}
	}
	/* handle other utility statements */
	else
	{
		CallPreviousProcessUtility(parseTree, queryString, context,
								   paramListInfo, destReceiver, completionTag);
	}
}
```

I think if we remodel the function like this, then:

 * It is more obvious what happens in each case,
 * Because now this is more clear and easy to understand, then we need less comments inside the function or before the function.

What do you think about this proposal?