Allow the user to configure the location of the mdbase type definitions

[aldrichtr]

Overview of changes

• Added additional field to the plugin settings structure at: settings.userMdbaseSpecLocation
• Updated the MdbaseSpecService to account for this setting (if enabled). The service will still use the default path (_types) if it is not configured.
• Updated the Integration tab in settings with a text field that allows the user to configure the path

Items remaining to be verified or completed:

• Provide translations for the new setting in the languages other than en
  • I do not know how to do this. If there is an automated process I am willing to do that,
    but I don't know how to test that the translations are accurate either.
• Confirm that there is no other service or function that expects the path to be the default _types.
  • I did a search through the repo for _types specifically, and updated it in all the locations that I found (other than the translations)

Manual testing

After running npm run build:test:

1. I opened the vault at tasknotes-e2e-vault. I opened the settings for the tasknotes plugin and confirmed that the new field is presented to the user, and that the user is able to add a path:

2. I confirmed that the task.md file had been created in the folder specified in the settings:

3. I confirmed that the mdbase.yaml file was created with the proper paths.

closes: #1757

[aldrichtr]

Just wanted to say thank you to the maintainers of this amazing plugin! I kept the changes as small as possible per commit so that it was obvious what was being changed. If you would like they can be rebased to just two. The settings and service changes; and the ui changes. Happy to modify in whatever way you want in order to fit in with your coding standards and build chain.

[aldrichtr]

This change requires further testing. Although the above manual tests are successful, the original _types folder also gets created and the property screen reverts to _types as well.

[callumalpass]

Thanks again for working through this and for documenting the manual testing. I think we should close this PR rather than merge it as-is because the current local fix takes a smaller route: TaskNotes now preserves an existing mdbase.yaml and reads its settings.types_folder when regenerating task.md, instead of adding a separate TaskNotes setting for the same path. That addresses the underlying custom-folder workflow while avoiding another settings field, i18n surface, and potential drift between TaskNotes settings and the mdbase collection config.

I have credited this PR's implementation exploration in the unreleased notes alongside #1853.