FPGATrackSim: add wildcard when missing a hit in road filter tools

The "wildcard" hit is added under some circumstances as a token that we are missing a hit in a layer. I think the original meaning of wildcard was to do with hit guessing-- as a sign that we should or should not guess the coordinates of the missing hit in a track. At the moment though, this functionality is unused and "wildcards" have been used instead as a quick test as to whether or not a road or a track is missing a hit in a layer-- a wildcard hit just means there were no hits found by the algorithm.

The road finder tools (e.g. the Hough transform) insert wildcard hits into a road if there are missing hits. They also set the "wildcard bit" for that layer, which is a bitmask hit map indicating the presence of a wildcard. This is a little redundant but it's the way things are currently implemented.

The road filter tools, particularly the eta pattern and phi road filter tools, can create new roads that may be missing hits in a given layer. They do not insert wildcard hits but only set the wildcard bit. This worked fine because the track fitter and other downstream code used the bitmasks to check for missing/wildcard hits, but it caused some issues when running the second stage or when making test vectors, because suddenly a track could have either wildcard hits OR "undefined" hits if a hit is missing, and accessing the metadata of an undefined hit can cause problems.

This commit fixes things so that, if the road filters are creating a road that's missing a hit in a layer, they insert a new wildcard hit object, exactly the same way that the road finders do. In a quick test it seems like this eliminated all the undefined hits in the output set of tracks. We may want to revisit this in the future if we change the meaning of "wildcard", but for now hopefully this is fine.

Tagging @jahreda and @tbold, as well as @jaoliver and @acamplan (who noticed this in test vector creation, thanks!), and @alancast (who I think noticed the same thing in the second stage and we just never fixed it...). We should confirm this does fix the problem in the test vector creation and that we don't need to do this anywhere else too.