analyze: use a common namespace for all local and global PointerIds

[spernsteiner]

Currently, each function has its own namespace for local PointerIds: PointerId::local(3) in function f is distinct from PointerId::local(3) in function g. This creates some problems for pointee type inference*. This branch puts all functions' local PointerIds into a common namespace, with each function occupying a different range in that space. This means each PointerId is now globally unique, and code that is analyzing one function can mention PointerIds from a different function without ambiguity.

Most analyses still only look at a single function; these use a sparse PointerTable that has entries only for global PointerIds (that is, PointerIds in the range allocated for globals) and for the local PointerIds of the current function. Any analyses that need to consider cross-function local PointerIds can use a single large GlobalPointerTable instead.

---

* The specific issue is this: the allocation in lighttpd's buffer_init is not initialized inside that function, so correctly inferring the type requires unifying type variables interprocedurally. The type variables for the pointee analysis are tracked in a VarTable, which contains LTys. We'd like to track variables from all functions in one big VarTable, so that we can unify variables that originated in different functions. However, LTys may contain local PointerIds, so a shared VarTable could mix up local PointerIds from different functions/namespaces, producing nonsensical results. The fix being applied here is to put all PointerIds into a single namespace, so all type variables can be tracked in a common VarTable, and there is no longer an obstacle to unifying type variables from different functions.

[ahomescu]

Why the rename?

[spernsteiner]

The function is currently unused, but I've left it in place for completeness of the API (NextGlobalPointerId has a fn new(), so the local version should too) and in case it's needed again in the future. To suppress the dead code warning, I prefer a leading underscore rather than #[allow(dead_code)] because it makes it more likely that anyone who starts using the function in the future will also remember to un-suppress the warning.