Fix DenseThreadId static destruction order fiasco

[bneradt]

I have verified that this resolves the centos crash we have been seeing in #12669

---

The _id_stack vector was being destroyed before thread-local _Id objects,
causing use-after-free when _Id::~_Id() tried to write to the freed vector.

This patch addresses this by using std::array instead of std::vector.
Since std::array<std::size_t, N> has a trivial destructor, the memory
remains valid to the threads trying to use it regardless of destruction
order.

This bug was latent and only exposed when linking order changed (e.g.,
when adding new source files that changed static initialization order).

Here's the valgrind output diagnosing the issue being fixed here:

  ==29149== Invalid write of size 8
  ==29149==    at 0x565832: DenseThreadId::_Id::~_Id()
  ==29149==    by 0x6126DD8: ??? (in /usr/lib64/libstdc++.so.6.0.19)
  ==29149==    by 0x6B40059: __cxa_finalize (in /usr/lib64/libc-2.17.so)
  ==29149==    ...
  ==29149==  Address 0xd4be1c0 is 0 bytes inside a block of size 2,048 free'd
  ==29149==    at 0x4C2B6DF: operator delete(void*, unsigned long)
  ==29149==    by 0x6B40059: __cxa_finalize (in /usr/lib64/libc-2.17.so)
  ==29149==    ...
  ==29149==  Block was alloc'd at
  ==29149==    at 0x4C2A593: operator new(unsigned long)
  ==29149==    by 0x566820: std::vector<...>::_M_default_append(unsigned long)
  ==29149==    by 0x56515C: __tls_init

[serrislew]

Thanks for working on this!