make bbolt to SQL migration process friendly to kubernetes and prepare to integrate the SQL migration process inside LND

Most of `lndinit` is geared towards helping to initialize and run LND from within a kubernetes environment. For example

- https://github.com/lightninglabs/lndinit/blob/main/README.md#example-use-case-2-kubernetes
- https://github.com/lightninglabs/lndinit/blob/main/example-init-wallet-k8s.sh

tells us how to initialize a wallet in kubernetes.

What is important to note is that these commands, if run a second time result in a no-op if they were already completed before. This allows them to be placed inside a kubernetes deployment startup script and if needed, they will do something on first start, if not, LND will restart normally all the other times. This allows a kubernetes deployment to have no changes required after the first startup to make the following startups work.

We should have a similar experience with `migrate-db`. We should be able to re-run it and it should be smart enough to move forward with no error if an appropriate SQL DB already exists, whether an old, non-SQL DB existed or not. I've created some more specific issues that I think we should fix to achieve this goal:

- https://github.com/lightninglabs/lndinit/issues/75
- https://github.com/lightninglabs/lndinit/issues/76
- https://github.com/lightninglabs/lndinit/issues/77

.

Also, if we can make these changes, then we will be testing the exact same workflow that we will need once we integrate the `migrate-db` process directly inside `lnd`. We plan do do this in later LND releases and I think we should start now by developing that workflow inside the external tool `lndinit` so that we can get testing out in the field on many nodes before we make this an automatic and integrated process inside of `lnd` for all nodes.

Read the README Kubernetes example and example-init-wallet-k8s.sh, then trace the migrate-db entry point and review linked issues #75-#77. Done means the migration workflow can be safely rerun from a Kubernetes startup process, including when an appropriate SQL database already exists, without errors.

Written by the indexing model from the issue text.