This patch a starting point for what's discussed in D118416, which is adding a resize capability to MDNodes.
We're distinguishing between small (< 16 operands) and large MDNodes, with the latter having their operands allocated in hung-off storage. Temporary and distinct MDNodes can be resized (to a larger operand capacity, they can't be made smaller), to which end a pointer to separately allocated hung-off storage is kept in the location of the co-allocated operands. This means that MDNodes with 0 operands ('tiny') need some extra space allocated for the pointer, which is not necessary for uniqued MDNodes with 0 operands. In order to distinguish the 2 tiny node types we use the concept 'tiny resizable' and 'tiny fixed' MDNodes (in addition to large and small). Note that this extra complexity could be eliminated if we're OK with allocating extra space even for uniqued tiny nodes. Only 2-3% of MDNodes seem to have 0 operands, so maybe this would not be a big deal.
The patch does not (yet) address the O(N) issue that arises from handling ModuleFlags of type "Append" during LTO, though it does fix the memory issue mentioned in 51893. For that we'd presumably want to scan all participating modules and reserve enough space for the operands from the start. This will be addressed in a later patch.
I didn't add a push_back() interface because there wasn't a client for it, but it can be easily added if needed. I named the resize method 'reserve' because we don't support shrinking anything.
For now, only MDTuples can be resized.
AFAICT, there is no effect on bitcode reading or writing.