Hier constraints from different files

[harrisonliew]

It appears that #675 commented out #626, which was one step towards getting vlsi.inputs.hierarchical.constraints to support meta directives.

Now, module-level constraints can come from different files, as long as vlsi.inputs.hierarchical.constraints_meta: append is set. Each file can contain part of the constraints for a given module. This addresses most of #401 I believe.

Ran thru a quick e2e mock test:

hammer-vlsi -p configs-design/pass/mock_hier.yml -p configs-design/pass/mock_hier_addl.yml syn-SubModC

Reviewing syn-SubModC/module_config.json files shows the correct module-specific config and syn-SubModC/syn-output-full.json shows SubModC's specific vlsi.inputs.hierchical.constraints not making it through.

TODO:

• Remove vlsi.inputs.hierarchical.manual_placement_constraints. This should be legacy and completely replaceable by using vlsi.inputs.placement_constraints inside the submodule's constraint dict.
• Fix upward propagation of constraints. Essentially need to remove module-specific constraints from the global output config dict from every action.
• Investigate if/why bumps still buggy after these fixes @kevindna

Related PRs / Issues

Closes #401

Type of change:

• Bug fix
• New feature
• Other enhancement

Impact:

• Change to core Hammer
• Change to a Hammer plugin
• Other

Contributor Checklist:

• Did you set master as the base branch?
• Did you state the type-of-change/impact?
• Did you delete any extraneous prints/debugging code?
• (If applicable) Did you add documentation for the feature?
• (If applicable) Did you update the poetry.lock file if you updated the requirements in pyproject.toml?
• (If applicable) Did you add a unit test demonstrating the PR?
• (If applicable) Did you run this through the e2e integration tests?
• (If applicable) Did you update the submodules in e2e/ if this feature depends on updated plugins?

[dpgrubb13]

LGTM