Fix old spec processing

[kfcampbell]

When working on #10, I came across build errors due to Kiota releasing their v1.0 major version. This PR:

• pins to a specific Kiota version (instead of installing the latest each time)
• bumps Kiota's Go dependency versions
• adds additional hacks to get Go compilation working again with the old hand-edited spec
• fixes the .NET generation and build process to work with the new major version of Kiota

Re: these hacks, at some point in the near future of generative SDK work they will need to be codified and solved for real, whether that's simply filtering out the broken endpoints, working with Kiota upstream, or discovering as-yet-hidden spec errors. However, I believe that's a task for another day given our current focus on the OpenAPI spec and linting.

Note that running the sample .NET application results in an error. I'm considering this out of scope for now as we don't have an automatically added sample Go application yet either.

[nickfloyd]

Is this PR simply scoped to updating Kiota only? I'm guessing you'll have a follow up that removes post processors and uses the 'NEXT' version of the descriptions?

[kfcampbell]

Is this PR simply scoped to updating Kiota only?

Yes, and updating the post-processors to correctly munge what Kiota spits out.

I'm guessing you'll have a follow up that removes post processors and uses the 'NEXT' version of the descriptions?

There will be a follow-up to switch to the next version of the descriptions, though post-processors will not go away entirely in the near future. Some issues (e.g. the one with the +1 and -1 schemas) are something we will continue having to update after generation is performed.

[kfcampbell]

We do have an ongoing opportunity for post-processor examinatino: it may be worth creating an issue at some point for simplifying them and auditing them for correctness/any broken or unnecessary functionality.