Mechanism for passing arbitrary extra config to formatters

Lots of formatters have extra config users may want to pass, and creating a top-level flag for each one will get cumbersome. We should consider a generic mechanism for passing flags through to formatters.

Factors to consider:
- These should be attached to the fine-grained formatter name, not the language, because we don't want to accidentally pass them to a different formatter that doesn't support them when the user switches formatter.
- Some might conflict with default flags. For instance, a user might want to pass `--type` to js-beautify and find that it conflicts with the `--type` flag we already pass by default.
- Most config would be per-path rather than global preferences. For instance, a user will want to configure an `--aosp` flag when working on Android Java, but then be surprised if it's applied to other Java code they're working on later.
- If possible, these config options should live in some project-local config file like `.clang-format` or `.editorconfig`, not something codefmt-specific, and codefmt should just try to be smart about detecting and not conflicting with such config where appropriate.

Issue nêu .clang-format và .editorconfig là các nguồn cấu hình cục bộ của dự án có thể sử dụng, đồng thời dẫn --type và --aosp của js-beautify làm ví dụ. Trước tiên, hãy lập sơ đồ cách các tùy chọn dành riêng cho từng formatter hiện được lựa chọn; được xem là hoàn tất khi có một cơ chế đã được quyết định theo từng formatter và từng đường dẫn, tránh các defaults xung đột và việc lan truyền ngoài ý muốn.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.