This patch is a first cut at solving the problem discussed in this thread

https://gcc.gnu.org/ml/gcc/2017-10/msg00016.html

where I have some nios2 backend patches in my queue that need a way of 
knowing whether the split1 pass has run yet.  There seemed to be 
agreement that a general way to query the pass manager for this 
information would be useful.

The approach I took here is to add a new counter field, so that I can do 
the test I want with

   opt_pass *split1_pass = g->get_passes ()->get_pass_split_all_insns ();
   if (current_pass->pass_number > split1_pass->pass_number)
     ...

Well, mostly.  :-P  There are some gotchas.

* TARGET_ASM_OUTPUT_MI_THUNK is called outside the pass manager (so 
current_pass is NULL) and on many targets this hook is implemented by 
setting reload_completed to 1, generating some RTL, and invoking some 
passes directly to emit code.

* modulo-sched.c also plays tricks with setting reload_completed to 
pretend to be something it's not.

* Possibly other places?  E.g. I'm not familiar with how plugins work.

For my purposes it's good enough to check reload_completed before the 
test in the code snippet above, but trying to determine whether a 
particular post-reload pass has run won't work.  So this isn't as 
general as it ought to be, at least not until we get rid of the 
reload_completed hackery.

Since this patch isn't useful without something that uses the pass 
counters, I tested it on nios2-linux-gnu with my not-yet-posted patch 
set, by wiring it up in parallel with my previously-implemented solution 
of adding a target-specific pass to set a flag, with various assertions 
to check for consistency.  I also had some temporary debugging code in 
there at one point to print the pass numbers.

WDYT?  Is this the right direction?  I'm somewhat worried that we're 
getting late in stage 1 and I'd really like to finish up my nios2 
patches; so if getting this right looks like a tar pit, I think I should 
probably stick with my previous implementation for now.

-Sandra