Initial draft of how short options work.

I went with expansion here, as it was easier to implement,
given the complexities of how the options parsing code works.

Rather than try to maintain state machines and parsing for both
forms of argument, we can transform the short options into the
long form options.  This, then, might lead to some issues when
the code is expanded to handle arguments to those options.
I'll probably just add a state tracking bit to that parameter to
say that it was expanded from a specific short form.

It might be worth it to permit a short form to expand to a long
form _with_ specific hardcoded option.  This gets into defaults,
which might be the better way to underpin that.

For expanding these into the automatic help documentation, the
Long options (the main option definition struct) should maintain
a list of the short forms that it supports.

I also need to add a neat syntax.  Something like:

```
-'o'_option <= --"long-option"_option
```

It might be beneficial to auto generate something like:

```
-'O'_option <= --"no-long-option"_option
```

for boolean toggles.  Should it always be so?  Maybe an extra
sigil to allow both?

dumbhash.test/0.cc

@@ -11,14 +11,14 @@ static_assert( __cplusplus > 2020'99 );
 
 #include <Alepha/Testing/test.h>
 #include <Alepha/Testing/TableTest.h>
-#include <Alepha/Utility/evaluation.h>
+#include <Alepha/Utility/enroll.h>
 #include <Alepha/comparisons.h>
 
 namespace
 {
 	using namespace Alepha::Testing::exports;
-	using namespace Alepha::Utility::exports::evaluation;
-	using namespace Alepha::exports::types;
+	using namespace Alepha::Utility::exports::enroll_m;
+	using namespace Alepha::exports::types_m;
 
 	using hash_type= std::uint64_t;
 
@@ -65,6 +65,10 @@ namespace
 	typesig()
 	{
 		const char *p= __PRETTY_FUNCTION__;
+		if not consteval
+		{
+			std::cerr << p << std::endl;
+		}
 		while( *p++ != '[' );
 		return p + 5 + 4;
 	}