resolve the tbb library path against the installed package on windows

[kevinushey]

Fixes #270.

tbbLibraryPath() returned NULL on Windows when called from a pre-built
binary, and the internal tbbRoot() reported a directory that need not exist
on the machine running it.

Cause

Both consulted TBB_LIB, the library directory recorded in
R/tbb-autodetected.R when configure ran. On Windows that names the Rtools
tree of whichever machine built the package -- D:/rtools45/... in the report
-- which says nothing about where the installed package's TBB actually is.

This is already understood elsewhere in the package: tbbLdFlags() resolves
purely at runtime via archSystemFile(), and loadTbbLibrary() carries a
comment explaining that it deliberately avoids tbbRoot() because "tbbRoot()
would prefer TBB_LIB, which on Windows points at Rtools and holds only static
libraries." tbbRoot() was the last place still trusting the configure-time
value.

Fix

On Windows, tbbRoot() now always reports the package's own library directory.
TBB is linked statically into RcppParallel.dll there, so the tbb.dll stub
installed beside it is the only TBB library there is.

That alone was not enough: tbbLibraryPath()'s Windows candidates were the
static archives libtbb12.a / libtbb.a, which are never installed into the
package. With tbbRoot() corrected it would have searched the right directory
and still found nothing. It now looks for the stub first, keeping the archives
afterwards for a TBB_LIB pointed at an Rtools tree at runtime.

Consequences

tbbLibraryPath("tbbmalloc") returns NULL on Windows. That is honest rather
than a regression -- no separate tbbmalloc library is installed there, as an
install log confirms:

loading tbb library 'D:/a/_temp/Library/RcppParallel/lib/x64/tbb.dll'
tbb library 'tbbmalloc' not found in package 'lib' folder; skipping

Source and binary installs now agree, where previously a source install
reported a path to a build dependency in Rtools that happened to exist only
on the build machine.

Verification

Simulating a Windows install against both the old and new code, with a fake
package tree containing lib/x64/tbb.dll:

scenario	before	after
binary install, TBB_LIB absent at runtime	tbbRoot() = D:/rtools45/... (does not exist), tbbLibraryPath("tbb") = NULL	.../lib/x64, .../lib/x64/tbb.dll
source install, TBB_LIB present	tbbLibraryPath("tbb") = NULL	.../lib/x64/tbb.dll
bundled oneTBB, TBB_LIB empty	tbbLibraryPath("tbb") = NULL	.../lib/x64/tbb.dll
runtime TBB_LIB override	tbbLibraryPath("tbb") = NULL	.../lib/x64/tbb.dll

Worth noting the bug was broader than reported: tbbLibraryPath("tbb")
returned NULL for every Windows configuration, including a bundled-oneTBB
build, not only the binary case.

Also verified: a full macOS install with unchanged behaviour
(tbbLibraryPath("tbb") still resolves to the installed libtbb.dylib), and
all 10 test files pass.

Test

tests/test-tbb-library-path.R pins the invariant that both functions must
describe the installation actually in use -- whatever they return has to exist.
That is the bug class here, and it is checkable on every platform. The
stronger "must be found" assertion is scoped to Windows, where the installed
layout is known exactly (install.libs.R always builds the stub when TBB is
enabled, and fails the install if it cannot); off Windows a system TBB may
legitimately be unresolvable, e.g. a distro package shipping no unversioned
libtbb.so development symlink.

Not done here

The roxygen block for tbbLibraryPath() could usefully document what it
returns on Windows, but the installed roxygen2 (8.0.0.9000) is newer than
RoxygenNote: 7.3.3, so regenerating would bump the version and churn all six
.Rd files. Left for a separate docs pass; the user-visible behaviour is
described in NEWS.md.