Extended timestamp field may be present in type 3 chunk headers

As described in Adobe’s RTMP specification dated 21 Dec 2012; also:

* RTMPY ticket #107, “Compressed headers also can have an extended
  timestamp”,
  http://web.archive.org/web/20120624031323/http://dev.rtmpy.org/ticket/107
* https://rarut.wordpress.com/2012/03/21/announcing-nginx-rtmp-module/

This resolves intermittent hangs, segfaults and crashes I was seeing when
starting ABC News 24 streams, e.g.:

rtmpdump -r rtmp://cp81899.live.edgefcs.net/live/news24-med@28772 --live

Some of the packets seemed to contain junk timestamp fields, which often
required the extended field.
Reconnect directly when authenticating, don't wait for the close message

This fixes authentication with wowza 4.x servers, which don't
send any close message in the authentication process.
Set RTMP_PUB_ALLOC if tcUrl is allocated in PublisherAuth

This makes sure we don't free tcUrl in RTMP_Close when reconnecting,
and avoids leaks (or simplifies code to avoid leaks).

This fixes connecting with authentication (both adobe and limelight)
when the app has been specified separately from the rest of the url.

This is only a temporary step while refactoring, this is removed
in a later commit.
Simplify the logic for freeing reused strings in RTMP_Close

Instead of having a plethora of flags indicating the current
state (just to avoid freeing them when closing the previous
connection when reconnecting), split RTMP_Close into CloseInternal,
taking a flag saying whether this is a reconnect or a normal,
final RTMP_Close call.

This also avoids leaks of some strings, if the whole session is
closed while the authentication process is underway.
Replace RTMP_PUB_ALLOC with RTMP_LF_FTCU and RTMP_LF_FAPU

This gets rid of the overlap between these two flags, shortening
the code somewhat.