feature.*: allow cop_feature to expand

[tonycoz]

The initial implementation of feature bits for faster access to feature flags used a single U32 member in COP to store the bits, but we're now up to 24 features, so rather than leaving this to the last minute I've re-worked regen/feature.pl to allow multiple U32 fields.

If you want to test this effectively you'll need to:

• add some features to %feature in regen/feature.pl, I added:

      "add1" => "add1",
      "add2" => "add2",
      "add3" => "add3",
      "add4" => "add4",
      "add5" => "add5",
      "add6" => "add6",
      "add7" => "add7",
      "add8" => "add8",
      "add9" => "add9",
      "add10" => "add10",
      "add11" => "add11",
      "add12" => "add12",
      "add13" => "add13",
      "add14" => "add14",
      "add15" => "add15",

• make regen
• update COP_FEATURE_SIZE in cop.h

and test.

The low alphabet names here force some existing features into the second word so you're actually testing access and handling of that second word.

---

• This set of changes does not require a perldelta entry.

[leonerd]

I wonder if it would make feature.h a bit less huge, if instead of storing a U32 mask and index per feature, we just had one "number" per feature and compiled the mask tests into something like:

if(cop.feature_bits[(num) / 32] & (1 << ((num) % 32)) { ... }

Those div and mod operators would be all operating on compiletime constants so they'd decompose into basically the same values we have anyway, and I think it'll all get compiled into the same stuff; just we'd only be storing one number per feature, as we do now, rather than those two separate ones.

[tonycoz]

I wonder if it would make feature.h a bit less huge,...

I'm a bit indecisive here - I've looked at the pre-processed source often enough that I prefer simpler macros (though the stable has long since burned down here for the perl source), but a single source of truth for the bits are good too.