So, I put these here when I realized that without them, the showAllApplications function would have to collect a list of badgeIds within, say, a system, and then do an enormous query where it checks if application.badgeId is in some enormous set of 1000 badge ids.  (we don't have a way in the api to do a join on the badge table where systemId=blah or whatever).  This struck me as painfully inefficient.

However, I also initially assumed that models/badge.js had these fields for the same reason, but now that I think about it I realize that in the case of Badge, those fields are actually necessary and not redundant data (though since we don't enforce only one of the fields being non-null, it actually does end up having redundant data as well).  This makes it way less gross in the case of Badge than I realized, and that grossness is what made me feel like doing this wasn't making things substantially more gross.  Now I realize that I am making things more gross here, so I am reconsidering it.

I suppose I can just do it the naive way of constructing the big ol' set of ids to query with, though we should definitely watch that for performance issues.  Alternatively, we could just not have routes for getting all applications by system, issuer, or program (you'd have to go badge by badge).  But that seems dumb.