Clarify more things about what works inside qt{} strings

[leonerd]

The original text did not explicitly mention that regular $foo interpolation does not work here, but it seemed implied so I've added some words.

I've also added a guess at some words to try to clarify what to do with \x-style escapes. I think people would get upset if they couldn't at least have \n for a linefeed, so by extension I suspect any of the escapes that just stand in for some other literal character would be fine. The only problem ones are the case/quotmeta ones, so I've explicitly disallowed those.

[rjbs]

I don't have strong feelings about this, but:

• if we don't allow them it's easy to use quotemeta, uc, lc, fc, and ucfirst (but there is no lcfirst)
• but what's the problem with allowing them?

That is: is it actually simpler to forbid qt/foo \l{ $obj->name } bar/ or to allow it? If it's easier to allow, it seems simpler to explain also.

[tonycoz]

• if we don't allow them it's easy to use quotemeta, uc, lc, fc, and ucfirst (but there is no lcfirst)
  There is lcfirst:

    lcfirst EXPR
    lcfirst Returns the value of EXPR with the first character lowercased.
            This is the internal function implementing the "\l" escape in
            double-quoted strings.

            If EXPR is omitted, uses $_.

            This function behaves the same way under various pragmas, such
            as in a locale, as "lc" does.

[rjbs]

Well, I feel foolish on that front! I'm sure I ran perldoc -f to check, but trying to reproduce that right now, I typoed ucfirst into ucfist and I bet I did that before, too.

[tonycoz]

As to the meat of your question, I don't think it makes a huge difference to the implementation, but with qt you can always do "... { lc $foo } ..."