Fix C# module smoketests

[bfops]

Description of Changes

#1440 restructured our NuGet packages, and correspondingly updated the .csproj files we generate. However, since we haven't actually published the restructured NuGet packages, .csprojs expecting the new NuGet package structure will be broken, including the smoketests.

It seems like this behavior was sometimes causing smoketests to fail. It's unclear why it's only sometimes, but our best guess is "something something caching", so this PR forcibly clears the NuGet package cache.

Additionally, we bump the versions of the local NuGet packages to 0.11, so that they cannot be found on the NuGet servers. This means that the smoketests can only find them in local directories, so they do not get confused about where to get these packages.

API and ABI breaking changes

No

Testing

• CI passes
• spacetime init --lang csharp followed by spacetime build works successfully
• smoketests pass when merged with [DO NOT MERGE] Timer tables implementation for C# #1459 in Bfops/test pr #1476

[Shubham8287]

Gets the job done!

[Shubham8287]

Oh wait, The PR in description fails with this error -

/tmp/tmp6wbnwk4t/Lib.cs(8,29): error CS0103: The name 'ColumnAttrs' does not exist in the current context [/tmp/tmp6wbnwk4t/StdbModule.csproj]

Is that means, error is specific to those PRs?

branch has changed meaningfully

[bfops]

clear package cache. this isn't required to make the CI work again, but there did seem to be some kind of caching happening because the smoketests weren't passing or failing consistently. This hopefully makes them more consistent.

[bfops]

(we think this also resolves a hypothetical issue where multiple open PRs make non-backwards-compatible changes to the NuGet packages)

[Shubham8287]

This feels like a good mitigation to fix the master. Thanks for working on this.
But I think there is still a need to have a general solution so that we don't run into the problem in future (not to be done by you or under the scope of this PR).

[bfops]

This feels like a good mitigation to fix the master. Thanks for working on this. But I think there is still a need to have a general solution so that we don't run into the problem in future (not to be done by you or under the scope of this PR).

The general solution is to bump the package versions when there are breaking changes