Revert to corresponding original login_help text for each affected language.

en/panel_login.xml had to be changed to enlarge certain fields for other
languages (rather than overriding sizes in each of several other languages).
Still need to translate new create_account_text and verify guessed log_in_text.

This includes replacing the small "Sign up" link with a "CREATE YOUR ACCOUNT:
Start now" button, requiring a small tweak to the C++ code to Do The Right
Thing when the button (vs. the link) is clicked.

It said it mapped to 'SkinFolder', which doesn't exist. 'SkinCurrent' is
correct.

Of course, preserve lang= localization from default skin.
Assume that localized steam/xui/*/strings.xml file without create_account_url key will
default to create_account_url key from steam/xui/en/strings.xml. That's how it
works in the default skin, anyway.

Splitting the 'add' from modifications unique to this skin facilitates code
review.

We have appropriate translations of the join.secondlife.com registration path,
but the Russian and Turkish [create_account_url] strings in strings.xml didn't
specify them. At Eli's request, added lang= params to these two.

The URL whose simple form is http://join.secondlife.com actually appears in a
number of places in the localized notifications.xml files. It's supposed to be
localized for the current viewer language -- and in strings.xml, it is. But
the same URL is restated a couple times in notifications.xml, sometimes
localized, sometimes not.
Add "create_account_url" to init_default_trans_args(), permitting us to embed
[create_account_url] anywhere in the skin files. Then replace all known
occurrences of that URL in notifications.xml files with [create_account_url].

We already have a "create_account_url" string in strings.xml, and in fact --
according to Eli -- the strings.xml values are "better" for non-English
languages. Unfortunately those "better" strings weren't being used. They were
tied to the FirstRun notification, which seems to have been disengaged.
Changed llpanellogin.cpp to look in strings.xml rather than panel_login.xml
when clicking the "Sign Up" link on the login panel.

Over the years we've skipped more and more of the tests in
llhttpclient_test.cpp (nee llhttpclient_tut.cpp) because they've relied on
particular behaviors from Internet sites not under our control.
We skipped a test that fetches llsd+xml from secondlife.com because
"secondlife.com is not reliable enough for unit tests."
We skipped a test that tries to observe a failure with "http://www.invalid"
because some local ISPs turn "no such domain" DNS errors into valid pages
offering the requester to buy the specified domain name.
Today we've had to skip tests attempting to contact "http://www.google.com"
for reasons we haven't yet diagnosed, but that probably have to do with
Google's IPv6 rollout.
Use local temp server test_llsdmessage_peer.py as the success destination,
eliminating DNS, Internet access and remote server behavior as failure modes.
Use idle localhost port for failure test.
Re-enable all skipped LLHTTPClient tests!
Re-enable on Windows!
In support of these tests, modify test_llsdmessage_peer.py:
Support HEAD as no-data variant of GET.
Change GET result dict to avoid resembling an error response -- confusing.
Make GET/POST return actual dict rather than undecorated string "success".
Because of that last, change llcapabilitylistener_test.cpp and
llsdmessage_test.cpp to extract "reply" key from response rather than
expecting response to be a string itself.

indra/test/llhttpclient_tut.cpp ==> indra/llmessage/tests/llhttpclient_test.cpp,
with corresponding CMakeLists.txt changes in their respective directories.
This first commit merely moves the test source file without changing it --
separating out moves from edits simplifies code review.

Today, 2012-06-06, LLHTTPClient::get("http://www.google.com/") has stopped
working. This is unrelated to viewer code changes: it crosses repo boundaries.
Skip the afflicted tests to get builds working until we can recast the tests
to avoid the flaky dependency.

The change from LLProcessLauncher to LLProcess introduces the possibility of a
NULL (default-constructed) LLProcessPtr. Add certain static LLProcess methods
accepting LLProcessPtr, forwarding to nonstatic method when non-NULL but doing
something reasonable with NULL. Use these methods in LLPLuginProcessParent.