fix multi-evals problems in pad name list api

The PAD_COMPNAME api, created in dd2155a49b , originally had alot of,
multi-eval problems, since av_fetch would be repeatedly called in macro
expansions. Later in commit b21dc0313d , an incomplete attempt at removing
multi-eval was done. Also in commit 035dab7448 added more multi-eval
problems. Prior to commit dd2155a49b , the code used a seemingly random
mix of av_fetch and AvARRAY, so both are ok. To fix this, replace av_fetch
with func-free AvARRAY. Since existing code has lval 0 to av_fetch and
unconditional deref on ret, a segv is fine to detect breakage.

A #define PAD_COMPNAME_SV(po) \
((assert(!SvMAGICAL(PL_comppad_name))),(AvARRAY(PL_comppad_name)[(po)]))
shows the AV is ! magical/tied during smoke. The assert was not added for
perf reasons on debugging builds. Inline funcs were not used for better
compiler optimizing if PAD_COMPNAME_FLAGS_isOUR is immediatly
followed by PAD_COMPNAME_OURSTASH (2 statements), as in scan_inputsymbol.
Inlines are not guaranteed to be inlined all the time on all compilers in all
situations, Visual C especially. Also inline is more likely to cause readding of
multi-eval problems than the macro if future changes to the API put the inline
func in a multi-eval macro.

On VC 2003 32bit .text section of perl521.dll dropped from 0xC296F to
0xC281F bytes of machine code with this patch.