Client-side exact projections

[shashwat-sh]

• Added in client-side exact projections and associated bool switch in the monitors.
• Added associated tests
• Name change: Near2Far -> FieldProjection everywhere
• Not rebased yet

Backend PR: https://github.com/flexcompute/tidy3d-core/pull/196

[tylerflex]

looks good to me!

[momchil-flex]

I have two comments that are not exactly related to the changes in the current PR, but they're something to think about in line with this ongoing refactoring.

1. First one is smaller and probably straightforward. It seems to me that monitor here and in other projection data classes should be a Field, and should be mandatory. A number of the in-built properties and methods depend on self.monitor and will break if a monitor is not stored in the data.

2. I am not a huge fan of how user-side projections currently work, e.g.

            projector = td.FieldProjector.from_near_field_monitors(
                sim_data=sim_data, 
                near_monitors=near_monitors,
                normal_dirs=['-', '+', '-', '+', '-', '+']
            )

            far_field_data = projector.project_fields(proj_monitor)

Specifically, I do not like that in the resulting far_field_data, the information about where the near fields came from (the near_monitors) is lost. You can thus for example end up with different values of the fields in two separate far_field_data instances without understanding why, because the stored self.monitor is the same (the supplied proj_monitor), but different near field data was used.

I thought about this and I realize that it's not straightforward to fix - I kinda understand why it is set up the way it is. But what about having a projection_surfaces list of FieldProjectionSurface instances in the ProjectionMonitorData classes? We can also add a projection_surfaces property to ProjectionMonitor classes which parse the supplied monitor geometry and exclude_surfaces, assigning normals correctly for a box. This could simplify some backend handling too. Then, if the monitor data is created from a server-side ProjectionMonitor, it will just have self.projection_surfaces == self.monitor.projection_surfaces. However, if it was created from near-field monitors user-side, it will store those monitors (and the supplied normal dirs) as projection_surfaces.

[shashwat-sh]

• Added a property integration_surfaces to SurfaceIntegrationMonitor which extracts surfaces and takes exclude_surfaces into account: see here

• Consequently was able to simplify backend processing a bit: see here

• Then specifically for projection monitors, I added projection_surfaces, as suggested by @momchil-flex , which makes use of integration_surfaces: see here. These are also included in the projection data now.

• Since the monitors now need access to FieldProjectionSurface, I have relocated that class from field_projection.py to monitor.py: see here

• Added a validator to check the range of ux, uy: here

I think this covers all the remaining loose ends except that precision issue for very far exact projections, but I suggest you review these changes in parallel to my trying to fix that, since it's more on the math / technical side and shouldn't affect the design.