token search for |<code> should only match codes with no systems

[lmsurpre]

Is your feature request related to a problem? Please describe.
Currently our SearchUtil.parseQueryParameterValuesString has logic like this:

                } else if (parts.length == 1 && v.endsWith("|") && v.indexOf("|") == v.length()-1) {
                    // Only a system was specified (uri followed by a single '|')
                    parameterValue.setValueSystem(unescapeSearchParm(parts[0]));
                } else {
                    // Treat as a single code.
                    // Optimization for search parameters that always reference the same system, added under #1929
                    if (!Modifier.MISSING.equals(modifier)) {
                        try {
                            String implicitSystem = searchParameter.getExtension().stream()
                                    .filter(e -> SearchConstants.IMPLICIT_SYSTEM_EXT_URL.equals(e.getUrl()) && e.getValue() != null)
                                    .findFirst()
                                    .map(e -> e.getValue().as(Uri.class).getValue())
                                    .orElse(null);
                            if (implicitSystem != null) {
                                parameterValue.setValueSystem(implicitSystem);
                            }
                        } catch (ClassCastException e) {
                            log.log(Level.INFO, "Found " + SearchConstants.IMPLICIT_SYSTEM_EXT_URL + " extension with unexpected value type", e);
                        }
                    }
                    parameterValue.setValueCode(unescapeSearchParm(v));
                }

That means its handling |<code> just like <code>. This is less efficient (see the performance guide) and also not quite right

Describe the solution you'd like
In our JDBC persistence layer we have an optimization whereby we store code with no system with a placeholder system.
The REST layer needs to somehow pass a placeholder like this to the Persistence layer so that we can distinguish between a search for no system vs a search for any system.

This can be the same placeholder or it could be a different one thats part of the contract. Either way, it should probably go into the javadocs somewhere.

Describe alternatives you've considered

Acceptance Criteria

1. GIVEN a target resource with a searchable Coding that has a system and a code
   WHEN we get a search like param=|<code>
   THEN it does NOT retrieve this resource

Additional context

[michaelwschroeder]

I verified this fix in my local development environment running the latest code from main. I ran the following searches:

1. searched on a token field using the <token-search-parm>=<code> form and verified that resources returned included those which specified a system value and those that did not.
2. searched on the same token field using the <token-search-parm>=|<code> form and verified that resources returned included only those which did not specify a system value.

I also inspected the generated SQL for the <token-search-parm>=|<code> search and verified that the common_token_value_id specified in the query was for a token that had a code_system_id of the default code system value, as expected.