Dodgy special-casing for String in promoteType

[RyanGlScott]

While investigating #358, I uncovered an oddity in the way promoteType is implemented. In particular, there's some dubious special-casing for String here:

singletons/src/Data/Singletons/Promote/Type.hs

Lines 43 to 45 in c776637

	go [] (DConT name)
	| name == typeRepName = return $ DConT typeKindName
	| name == stringName = return $ DConT symbolName

Here is what is dubious about it:

• This case is very unlikely to ever be reached in practice. That's because singletons is quite eager to expand type synonyms when possible, which means that you'll usually pass types to promoteType which mention [Char] instead of String.
• Even if this case were reached, what is it doing here? We certainly don't have any special case that turns, say, Natural into Nat, so it feels odd to turn String into Symbol. (And for that matter, shouldn't it be that we turn Text into Symbol instead?)

I can think of two possible options here:

1. Remove this special case entirely.
2. Fix the special case to turn Text into Symbol, and add a corresponding case for turning Natural into Nat.

[goldfirere]

That code likely predates Natural and quite possibly singletons's attempts at synonym expansion. I'm not wedded to it -- remove the line if it's getting in your way.

[RyanGlScott]

It's not actively getting in my way per se, but it does smell odd.

Speaking of odd smells, there's another case in promoteType that I just noticed which really makes my nose curl:

singletons/src/Data/Singletons/Promote/Type.hs

Line 53 in 5f867ac

go _ (DLitT _) = fail "Cannot promote a type-level literal"

Why can't we promote type-level literals? Isn't promoting them a no-op? Currently, this prevents this (relatively obscure) code from working:

$(promote [d|
  f :: Proxy 1 -> Proxy 2
  f Proxy = Proxy
  |])

[goldfirere]

That looks like a historical accident to me. I see no trouble promoting literals like that.