Support for CMake find_package and imported targets

[asasine]

I'm curious and wondering if the maintainers are open to adopting a more standard approach to pico-sdk's CMake integration based on the CMake's guides for package maintainers, including Using Dependencies, Import and Exporting, and Finding Packages. Finding and linking to libraries in a modern CMake project typically utilizes find_package(...) calls, linking to namespaced imported targets, and doesn't require library-specific CMake macro/function calls to "fully initialize" the dependency like pico_sdk_init(). A limited example would look like this:

project(my_project)
find_package(pico-sdk REQUIRED)
add_executable(hello_world src/hello.cpp)
target_include_directories(hello_world include)
target_link_libraries(hello_world pico_sdk::pico_stdlib)

As I see it, only one change is required to get this to work with some lifting on the user's part. Removing the requirement to include pico_sdk_init.cmake before the project(...) call allows users to write their own FindPicoSdk.cmake, thus gaining a similar experience to pico-sdk shipping CMake configuration files. If anyone knows why, I'd love to know what in that CMake file makes this a requirement; nothing obvious stood out to me when I read through it.

Optionally, pico-sdk can fully support CMake conventions with some additional changes:

1. During the pico-sdk build, create and install(...) a CMake export set and a package configuration file (version files optional but good too).
2. Provide new installation instructions for adding pico-sdk via CMake config mode, such as cloning to the local administrator path (/usr/local/) or elsewhere (e.g., /opt or ~/.local/); or ship a system package pico-sdk-dev that installs sources to system paths directly (/usr/)

Let me know what you think about this proposal. I have experience writing and maintaining CMake packages and would be happy to jump in to making improvements and fixes.

[kilograham]

We are certainly interested in being more standards compliant.... seems like it might be a bit of a backwards incompatibility so positing a 2.0 SDK release

[asasine]

2.0 seems fine to me. What's the process to get this contributed? There'll need to be some decisions made on where/how installation is performed (e.g., src or binary distribution, installation path).