Decide which functionality should be public

[Pennycook]

Feature/behavior summary

Direct access to the internals of the codebasin package was deprecated in CBI 1.2, to give us time to refactor and finalize the public interface. The purpose of this issue is to track progress towards defining a clear boundary between public and private interfaces.

I expect that this will take us a long time to complete, and suggest that we do it incrementally.

Request attributes

• Would this be a refactor of existing code?
• Does this proposal require new package dependencies?
• Would this change break backwards compatibility?

Related issues

• Explore use of pathlib instead of os.path #58
• Refactor configuration dict into CompilationDatabase #100
• Refactor setmap into an object #135
• Move MetaWarning classes into new module #142 (_detail package)

Solution description

For each class and function in codebasin, we need to decide:

1. Whether it should remain a public interface that we commit to maintaining; and
2. Whether it needs refactoring before committing to a public interface.

Additional notes

• @laserkelvin suggested that private globals (e.g., the _compilers dictionary) could be replaced by a registry (see Add compiler definitions #168 (comment)).