feat: Position & momentum unbounded operators

[gloges]

Continues on from #957 and makes progress on #851.

Introduces schwartzEquiv, the LinearEquiv between Schwartz functions and their image in the Hilbert space, along with some basic properties. This bijection is then used to define three symmetric unbounded operators with Schwartz submodule for domain, using the previously-defined continuous linear maps on Schwartz functions. These are the position and momentum unbounded operators, defined component-wise, and the (regularized) radius operator to any real power.

There remains one sorry which will have to be revisited. Showing that the momentum operator on Schwartz functions is symmetric requires two results for Space.deriv: integration-by-parts over all of Space d and commutation through complex conjugation.

[morrison-daniel]

Apologies for not getting to this sooner, but I have been thinking about your PR. I think everything you've done here is reasonable in terms of the existing API and how the literature is written but I wonder if it makes sense for us to change up how UnboundedOperator is defined to make things smoother for Lean formalization. What doesn't feel quite right to me is

/-- The position operators defined on the Schwartz submodule. -/
def positionOperatorSchwartz : schwartzSubmodule d →ₗ[ℂ] schwartzSubmodule d :=
  (schwartzEquiv (d := d)) ∘ₗ 𝐱[i].toLinearMap ∘ₗ (schwartzEquiv (d := d)).symm

Like I said, why you'd do this makes sense with how things are designed, but needing to use schwartzEquiv to move back and forth between the Schwartz subspace seems like a complication that is going to bite us in the long run. I wonder if it would make more sense to have UnboundedOperator between two different spaces, even if we only intend to use them between the same space because Lean sees the submodule it's defined on as a different space than the entire Hilbert space. So I'm thinking it might be smart to adjust the API before we get too deep.

Unfortunately that would delay this PR but I think it might save some headaches in the long run. Does this reasoning make sense, and do you think this would be a productive change?

[jstoobysmith]

@morrison-daniel Could you give your suggested definition for UnboundedOperator here?