Implement provider population on demand

Right now, "static" providers (pretty much anything other than pid-providers, USDT-providers, and profile/tick) populate the list of known probes for every dtrace invocation. Probe matching is done based on the list of known probes. This is at times overkill because we really only care about probes that match the probe descriptions of the clauses that are used in a tracing session.

One fairly easy way to optimize this is to only populate the probes for providers that match the probe specifications. In other words, probe population in a given provider can be done on-demand the first time that the provider is identified as a possible source of probes we are interested in. To do this, we can implement a callback in the provider implementation to register the provider without actually populating it with any probes. Then, when probe matching involves a provider whose probes have not been populated yet, populate them, record that population took place, and then try to match any of its probes.

A more complex way would refine this even more by only populating those probes that match the probe specification. That is more efficient in terms of memory usage but it may actually be slower in performance because compilation of multiple clauses may require evaluating the probes in a particular provider multiple times since later clauses may be interested in probes within the same provider, but ones that thus far did not match any probe specifications.

I would suggest that we implement the first solution and then consider whether the second solution is worth evaluating.

Start with the provider implementation and probe-matching path described in the issue. Trace how providers register and how matching triggers population. Done means static providers are registered without probes, populated once when matching first identifies them, and their probes are then matched; existing behavior for pid, USDT, and profile/tick providers should remain unchanged.