Allow dots in usernames (incomplete - should use nodeprep)

This allows users with gmail accounts to work correctly.

NOTE: gmail accounts have interesting issues with dot-stuffing
and subscription as well...
Local Delivery: replace "jabber:server" namespace with "jabber:client"

This was causing significant interoperability issues.

RFC 6120 is quite clear on this:

4.8.3. XMPP Content Namespaces

[...]

   Server implementations MUST support as default content namespaces
   both the 'jabber:client' namespace (when the stream is used for
   communication between a client and a server) and the 'jabber:server'
   namespace (when the stream is used for communication between two
   servers).  When communicating with a connected client, a server MUST
   NOT send stanzas qualified by the 'jabber:server' namespace; when
   communicating with a peer server, a server MUST NOT send stanzas
   qualified by the 'jabber:client' namespace.

      Implementation Note: Because a client sends stanzas over a stream
      whose content namespace is 'jabber:client', if a server routes to
      a peer server a stanza it has received from a connected client
      then it needs to "re-scope" the stanza so that its content
      namespace is 'jabber:server'.  Similarly, if a server delivers to
      a connected client a stanza it has received from a peer server
      then it needs to "re-scope" the stanza so that its content
      namespace is 'jabber:client'.  This rule applies to XML stanzas as
      defined under Section 4.1 (i.e., a first-level <message/>,
      <presence/>, or <iq/> element qualified by the 'jabber:client' or
      'jabber:server' namespace), and by namespace inheritance to all
      child elements of a stanza.  However, the rule does not apply to
      elements qualified by namespaces other than 'jabber:client' and
      'jabber:server' nor to any children of such elements (e.g., a
      <message/> element contained within an extension element
      (Section 8.4) for reporting purposes).  Although it is not
      forbidden for an entity to generate stanzas in which an extension
      element contains a child element qualified by the 'jabber:client'
      or 'jabber:server' namespace, existing implementations handle such
      stanzas inconsistently; therefore, implementers are advised to
      weigh the likely lack of interoperability against the possible
      utility of such stanzas.  Finally, servers are advised to apply
      stanza re-scoping to other stream connection methods and
      alternative XMPP connection methods, such as those specified in
      [XEP-0124], [XEP-0206], [XEP-0114], and [XEP-0225].
Encode XML using entities for high-byte chracters

There appears to be a bug in the SSL handling in Pidgin
where it's counting bytes vs characters, and with a long
roster containing multibyte characters, it corrupts the
XML by randomly skipping some characters.

This bug is somewhat insane, but it's work-aroundable
by just sending all high-byte characters encoded as
numbered (hex) entities.

It would be nice to be smarter about quoting of quotes,
but this seems to interoperate fine.
Decode XML entites in Attributes

We run without external entity parsing for security, but this
means we don't parse regular named or numbered entities either,
which breaks setting "Bob & Sue Jones" as a JID name in your
Roster.

This is fixed by using HTML::Entities to parse the 'Attributes'
in SAXHandler.
Test: test parsing XML entities in both attributes and text
Merge pull request #21 from brong/bugfixes

Bugfixes - XML entities, dots in usernames, local delivery namespace
Merge pull request #20 from gittex/debinitfix

Improve debian package upgrades
Don't leave eval via next

Eval is not a loop and as such should not be left
using loop control statements.

This commit replaces those next statements with return
statements. The control flow should be exactly the same
since the enclosing loop will move on to the next iteration
after a successfull return from the eval.