Update disable_users_coredumps.xml

Hard or '-' works because '-' sets both hard and soft.
While the observation / catch behind proposed enhancement of this OVAL check is correct (the OVAL object comment mentions it will be checking for both (hard|-) values and also ```limits.conf``` manual page suggests when '-' character at particular field is used, both soft & hard resource limits will be enforced), the current implementation is wrong.

The problem is in the form the new regex is written - while the intention is to allow both ```hard``` and ```-``` values to be allowed in the second column of the core row of /etc/security/limits.conf, the regex instead of allowing both of these options defines new regex match group with id #1 (due to adding brackets):
* the first captured group will be either ```hard``` or ```-```,
* the second capturing group will be the actual number setting (4-th column of the core row)

meaning the new implementation won't pass even when the system is configured properly. Data collected from the system with new implementation:
```
        <collected_objects>
          <object id="oval:ssg:obj:2230" version="1" flag="complete">
            <reference item_ref="1044271"/>
          </object>
        </collected_objects>
        <system_data>
          <ind-sys:textfilecontent_item id="1044271" status="exists">
            <ind-sys:filepath>/etc/security/limits.conf</ind-sys:filepath>
            <ind-sys:path>/etc/security</ind-sys:path>
            <ind-sys:filename>limits.conf</ind-sys:filename>
            <ind-sys:pattern>^[\s]*\*[\s]+(hard|-)[\s]+core[\s]+([\d]+)</ind-sys:pattern>
            <ind-sys:instance datatype="int">1</ind-sys:instance>
            <ind-sys:line>^[\s]*\*[\s]+(hard|-)[\s]+core[\s]+([\d]+)</ind-sys:line>
            <ind-sys:text>*     -   core        0</ind-sys:text>
            <ind-sys:subexpression>-</ind-sys:subexpression>
            <ind-sys:subexpression>0</ind-sys:subexpression>
          </ind-sys:textfilecontent_item>
        </system_data>
```

As can be seen in the new implementation there will be two subexpressions, one of them ('-') not matching the requirement ('0'), therefore the check will fail also on properly configured system.

To fix the problem the regex modification should be to use non-capturing group for the first case, IOW something like:
```
+ <ind:pattern operation="pattern match">^[\s]*\*[\s]+(?:hard|-)[\s]+core[\s]+([\d]+)</ind:pattern>
```
so the first regex match group remains the digit one, and only that one will be compared with expected state.