package-lock.json shows up as a component - false positives in compliance

### Current Behavior

Hi, I'm not sure yet whether this should be seen as a question, request or bug report.

I've noticed that DT lists `package-lock.json` as a component. It kind of makes sense when looking at the dependency tree, but otherwise it's not really a *component* of the app. It also does not have any license information and hence gets flagged as unresolved.

I don't know if the license would be picked up if I had any in my package.json, but if it did it would be a non-free license (company internal) and then show up as a false positive policy violation.

It might also just be an issue with trivy, which generated:
```json
{
"bom-ref": "a5d557f0-e70a-41b8-98bc-7037e70ec009",
"type": "application",
"name": "package-lock.json",
"properties": [
{
"name": "aquasecurity:trivy:Class",
"value": "lang-pkgs"
},
{
"name": "aquasecurity:trivy:Type",
"value": "npm"
}
]
},
```

### Proposed Behavior

I'm not sure if it should be a component at all. If so, shouldn't it have the *name* of my app instead of package-lock.json?

Given that it makes sense to have this at all - I'd need a way to tell DT that this is *my* component and that the license information of this very component is to be ignored (not its children, though).

It might suffice if in the policy editor I'd be able to add a condition like `componentName != package-lock.json`. But there currently doesn't seem to a way to use component names in conditions.

### Checklist

- [X] I have read and understand the [contributing guidelines](https://github.com/DependencyTrack/dependency-track/blob/master/CONTRIBUTING.md#filing-issues)
- [X] I have checked the [existing issues](https://github.com/DependencyTrack/dependency-track/issues) for whether this enhancement was already requested