- Won't work, because you can't legally call it the GPL; see eg the GPL FAQ:
You can legally use the GPL terms (possibly modified) in another license provided that you call your license by another name
The practical upshot is that only the FSF can issue versions of the GPL.
configure would be a derivative work of a GPLv2+ licensed file, which must therefore be licensed under GPLv2+ as per GPLv2 ss 3, 2b.
That would be a simple manual copy, which must therefore be licensed under GPLv2+ as per GPLv2 s1.
It's a derivative work, see above, unless you do a clean-room reimplementation. You cannot do that on your own.
The licence on
autoconf is not a problem, as long as you're not distributing it. The licence on a program does not (generally) affect the licence status of the program's output; the licence on the program's inputs do, hence point 2 above.
Basically, none of the options you list are legitimate. The author of the
configure.ac file you link to did not intend for you to be able to release it under an MIT licence, and has signalled his intent by picking a licence that forbids such release.
An argument could be made, however, that the compilation environment of a work is not the work itself. Having an MIT codebase the compilation of which is directed by a series of files under GPL, when all these files are distributed together, isn't immediately obviously a GPL violation (at least, not to me). Certainly if you shipped a GPL compiler with your MIT code, it would be possible for the compilation environment in the field to invoke the compiler without the compiler's licence bleeding into the main, MIT-licensed code. It's not clear to me that files that direct the operation of the compiler are more tightly coupled to the main code, in a copyright or licensing sense, than the compiler itself.
If you're betting a company on this, however, take professional legal advice first. If you're not, it might be simpler just to release your work under GPLv2+, and remove any risk.