Revert part of "DRTVWR-575: Address review comments on Xcode 14.1 type tweaks."
Crash was reproduced when assigning areastr to llsd, but likely present in other cases of assigning ui strings to llsd (instead of going for lluistring's result directly copy constructor was engaged and either copy or original crashed due to invalid pointers, copy shouldn't have been created).

One could argue that passing a negative index to an LLSD array should do
something other than shrug and reference element [0], but as that's legacy
behavior, it seems all too likely that the viewer sometimes relies on it.

This specific problem arises if the index passed to operator[]() is negative
-- either with the previous Integer parameter or with size_t (which of course
reinterprets the negative index as hugely positive). The non-const
ImplArray::ref() overload checks parameter 'i' and, if it appears negative,
sets internal 'index' to 0.

But in the next stanza, if (index >= existing size()), it calls resize() to
scale the internal array up to one more than the requested index. The trouble
is that it passed resize(i + 1), not the adjusted resize(index + 1).

With a requested index of exactly -1, that would pass resize(0), which would
result in the ensuing array[0] reference being invalid.

With a requested index less than -1, that would pass resize(hugely positive)
-- since, whether operator[]() accepts signed LLSD::Integer or size_t,
resize() accepts std::vector::size_type. Given that the footprint of an LLSD
array element is at least a pointer, the number of bytes required for
resize(hugely positive) is likely to exceed available heap storage.

Passing the adjusted resize(index + 1) should defend against that case.

LLFloaterLandHoldings::postBuild() was constructing an LLSD structure by
assigning each map entry and array element one at a time. Chorazinallen
identified a crash bug possibly caused by destroying that LLSD structure.
Diagnostically try building it using nested llsd::map() and llsd::array()
calls instead to see if that improves matters.

The compiler was deducing an unsigned type for the difference (U64 desired
microseconds - half KERNEL_SLEEP_INTERVAL_US). When the desired sleep was less
than that constant, the difference went hugely positive, resulting in a very
long snooze.

Amusingly, forcing that U64 result into an S32 num_sleep_intervals worked only
*because* of integer truncation: the high-order bits were discarded, resulting
in a negative result as intended.

Ensuring that both integer operands are signed at the outset, though, produces
a more formally correct result.

It seems newer compilers have a different interpretation of exactly when to
engage LLSDArray's copy constructor. In particular, this assignment:

some_LLSD_map[key] = LLSDArray(...)(...)...;

used to convert the LLSDArray object directly to LLSD; now it first calls the
custom copy constructor, which embeds the intended array within an outer array
before assigning it into the containing map.

The newer llsd::array() function avoids that problem because what it returns
is already an LLSD object.

Taking inventory of LLSDArray assignments of that form turned up a number of
workarounds like LLSD(LLSDArray(...)). Replacing those with llsd::array() is
both simpler and more readable.

Tip of the hat to Chorazinallen for surfacing this issue!

The unsigned index arithmetic was problematic in that case.

Since LLSDSerialize::SIZE_UNLIMITED is negative, passing that through unsigned
size_t parameters could result in peculiar behavior.

and use it to replace dubious loops in asLLSD() and trimEmpty().

Introduce LLSD template constructors and assignment operators to disambiguate
construction or assignment from any integer type to Integer, likewise any
floating point type to Real. Use new narrow() function to validate
conversions.

For LLSD method parameters converted from LLSD::Integer to size_t, where the
method previously checked for a negative argument, make it now check for
size_t converted from negative: in other words, more than S32_MAX. The risk of
having a parameter forced from negative to unsigned exceeds the risk of a
valid length or index over that max.

In lltracerecording.cpp's PeriodicRecording, now that mCurPeriod and
mNumRecordedPeriods are size_t instead of S32, defend against subtracting 1
from 0.

Use narrow() to validate newly-introduced narrowing conversions.

Make llclamp() return the type of the raw input value, even if the types of
the boundary values differ.

std::ostream::tellp() no longer returns a value we can directly report as a
number. Cast to U64.

llssize is for a function parameter that should accept a size or index
(derived from size_t, which is 64 bits in a 64-bit viewer) but might need to
go negative for flag values. We've historically used S32 for that purpose, but
Xcode 14.1 complains about trying to pass size_t to S32.

narrow() is a template function that casts a wider type (e.g. size_t or
llssize) to a narrower type (e.g. S32 or U32), with validation in
RelWithDebInfo builds. It verifies (using assert()) that the value being
truncated can in fact fit into the target type.

It's a little distressing how often we have historically coded S32 or U32 to
pass a length or index.

There are more such assumptions in other viewer subdirectories, but this is a
start.

Or rather, attempting to implicitly sign. On TeamCity we must explicitly sign
using viewer_manifest.py. On a developer system, without these changes, Xcode
produces many errors of the form:
error: An empty identity is not valid when signing a binary for the product
type 'Command-line Tool'. (in target 'INTEGRATION_TEST_lldir' from project
'SecondLife')
and refuses to compile anything at all.

Thanks to Rye Mutt and NickyD. Also thanks Geir Nøklebye for additional
settings to help tame Xcode 14.1 warnings.

following promotion of DRTVWR-575

Fix SL-18511 TOS and MFA login failure handlers must cooperate to answer both reasons at the same time

following promotion of DRTVWR-574

following promotion of DRTVWR-548

Since the performance overhaul project, there should be essentially no difference between rigged meshes and non-rigged as far as vertex buffer management is concerned.

It might be safe to merge mSeedCapAttempts with mHttpResponderID, but for now leaving them separated, if only for making this mechanic clearer.

# Conflicts:
#	indra/newview/llmodelpreview.h