Split custom_badges_really_ordered

Fixes #545 by splitting custom_badges_really_ordered into add_custom_badges and shift_custom_badges.

Keep in mind that the logic has flipped - shift_ and add_ need to be True by default.
This was a good change, but since the behavior is now different, the tests are broken.  What we'll need to do is add another set of fixtures like so:

```python
make_setting_fixture('custom_badges_addable', 'ADD_CUSTOM_BADGES', True)
make_setting_fixture('custom_badges_gone', 'ADD_CUSTOM_BADGES', False)
```

Which could then be used in unit tests.

Although actually, now that I think about it, a better approach might be to always have the ADD be true, and just use the badge ranges to indicate a maximum.  Like let's say we have 473 staffers and print 25 extra blank staff badges.  We could make the badge range for staff badges 1-498 and then not bother with this new ``ADD_CUSTOM_BADGES`` setting.

Using the badge ranges stuff, would also be better because it's more flexible by badge type.  If we have multiple custom badge types and run out of one but not the other, then we can't set ``ADD_CUSTOM_BADGES`` to ``False`` since we still want to be able to add one type.  But if we're just using badge range checks, we can set the max appropriately and it'll be fine for both cases.  That's also better because someone won't need to change a setting and restart the server to change whether or not people an assign new staff badges on-site.