Suricata

With the following smb pcap and two simple rules, we were able to reproduce a severe bug in 6.0.9 and 7.0 Beta/Master.

The following two rules trigger the bug:
```
alert ssh $HOME_NET any -> any any (msg:"pcre without content"; pcre:"/rabbit/B"; sid:1; rev:1;)
alert smb $HOME_NET any -> any any (msg:"smb share content"; smb.share; content:"C"; sid:2; rev:1;)
```
The second rule for smb would match and trigger 4 alerts on itself, but as soon as the first rule is parsed and registered as well, the second rule won't match anymore.

If you add a `content` match to the first rule it works again and generates 4 alerts:
```
alert ssh $HOME_NET any -> any any (msg:"pcre with content"; content:"r"; pcre:"/rabbit/B"; sid:1; rev:1;)
alert smb $HOME_NET any -> any any (msg:"smb share content"; smb.share; content:"C"; sid:2; rev:1;)
```

It seems to be related to `DETECT_SM_LIST_PMATCH` somehow overwriting parts that are relevant for the second rule.

The impact could be quite relevant, once we added such a dummy rule we did some tests and for example within a malicious pcap used against the ET ruleset, the alerts went down from around 890 to 850 so a rule that doesn't even match can have an impact on the amount of valid alerts.

Using the `pcre` is just on example, other keywords that use `DETECT_SM_LIST_PMATCH` also have the potential to break other rules.