fix test_conversions argument parsing

[bashbaug]

fixes #281

There's still a LOT of additional improvements that could be made here, but I think this is progress in the right direction and it fixes the specific issues.

I can kick off PoCL testing, but I'm not sure what command lines would be most useful. Right now, we're not able to list tests for this suite, so there's just one entry in the output json for "conversions" no matter how many tests run.

In case it's helpful, here are the cases I tested manually, and the behavior I observed:

Command	Result
test_conversions CL_DEVICE_TYPE_CPU	Requests CPU device, runs the full suite from test 0
test_conversions uchar_char CL_DEVICE_TYPE_CPU	Requests CPU device, runs convert_uchar( char ), PASSED sub-test.
test_conversions uchar_char ulong_sat_rtp_float CL_DEVICE_TYPE_CPU	Requests CPU device, runs both conversions, PASSED 2 of 2 sub-tests.
test_conversions uchar_char pid0 id0 CL_DEVICE_TYPE_CPU	Uses platform index 0 and device index 0, runs convert_uchar( char ), PASSED sub-test.
test_conversions 100 CL_DEVICE_TYPE_CPU	Requests CPU device, starts at test 100, 100) Testing convert_ucharn( longn )
test_conversions conversions CL_DEVICE_TYPE_CPU	Requests CPU device, runs the full suite from test 0, not sure if this is the desired behavior but this is unchanged
test_conversions uchar_chr CL_DEVICE_TYPE_CPU	ERROR: The argument 'uchar_chr' did not match any test names.
test_conversions	Requests default device, runs the full suite from test 0
CL_DEVICE_TYPE=cpu test_conversions	Requests CPU device based on environment variable, runs the full suite from test 0
test_conversions -[12] id0	Uses device index 0 and a wimpy reduction factor of 12, runs the full suite from test 0
test_conversions --list	Lists conversions, unchanged, this is something we should fix!
test_conversions -q	-q <-- unknown flag: q (0x71) followed by the usage message, unchanged

[bashbaug]

@gwawiork mind giving this a quick review? I can't add you as a reviewer. Thanks!

[rjodinchr]

I really don't like the direction this is taking.
To me the proper way to fix that test is with rjodinchr@0836e3a
With that commit, we make the harness aware of the subtest name of conversions. It fixes the listing capability of the harness, but as well, it allows the harness to know what a subtest name look like, removing the need to hack the harness to keep the subtest list in the conversions source code.
On top of that, it brings features like wildcarding to the conversions test as it is implemented by the harness.

But that commit depends on harness registration changes from #2754
That PR was approved 1 month ago, but I'm still waiting for an approval after rebasing it to resolve the conflicts.
Right now the conversions commit does not apply easily on top of that PR, but I'm waiting for it to be merged to rebase my conversions changes and send a PR.

[rjodinchr]

I've rebased my work, so after #2754 is merged, here is the commit that will be needed to fix rjodinchr@c587e1b

I've tried the cases above with it.

[bashbaug]

Sorry about that, I can see how "progress in the right direction" in my PR description was misleading, my fault.

Let's try again: This PR is intended to be a narrow fix for the immediate problem that doesn't make things worse. This test and its argument parsing in particular are still a bit of a mess, even with this PR (so many global variables). So, if we want to drop this PR completely in favor of a more comprehensive solution, that's fine. Or, if we want to merge it as a temporary fix that gets rewritten sometime in the future with a proper fix, that's fine too.

Re-reviewing #2754 has been on my TODO list. I'll try to get to that today, then perhaps we can figure out what to do next?

[rjodinchr]

I don't want to block you, but I think I'll just make a clean revert bundled with rjodinchr@c587e1b once #2754 is merged.